Re: [MBONED] addrarch: IANA allocations and assignments

[Marshall Eubanks <[e-mail]>]

Hello;

On Dec 20, 2006, at 10:33 AM, David Meyer wrote:

> 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?

http://tools.ietf.org/html/draft-ietf-mboned-ipv4-uni-based-mcast-02

>
>>     - 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.
>

Indeed. Most (effectively all) of the iron and silicon that is going  
into IPTV deployments
is IPv4 and ASM, and doesn't support IGMPv3

> 	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.
>

Is there a public list of these ?


> 	--dmm

Regards

Marshall

> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mboned


_______________________________________________
MBONED mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mboned