All things related to multicast

[Leonard Giuliano <>]

Sure, that's a good rule of thumb, but look at the blocks of addresses we
are talking about here: 225/8-231/8, 234/8-238/8.  It's not as if
allocations are made from this block on a daily basis.  In fact, it's
probably been years since any changes have been made in this space.

This is roughly analogous to saying don't block unicast bogon addresses,
unless you have an automated way to check the ARIN allocations.  How often
does the bogon list change??

Based on the amount of damage that worms have been doing lately, it seems
that the benefits of taking this huge block of space out of play far
outweigh the costs of supporting the unfettered access to it.  Why would
you want to allow full interdomain support for routing and forwarding of
these reserved/unassigned addresses?  Would you do that for unicast?

Continuing to update the Mcast-Unusable draft with some long list of
arbitrarily selected addresses seems like a losing proposition.


Of course, there has been a proposed scheme to make assignments in 225/8,
but I can't think of any other ideas on the horizon that would use this
space, though.

http://www.ietf.org/proceedings/02nov/I-D/draft-ietf-mboned-ipv4-uni-based-mcast-00.txt


-Lenny

On Tue, 2 Sep 2003, Bill Nickless wrote:

-) My $0.02;
-)
-) Please don't block multicast group addresses, unless you have an automated
-) way to check the ARIN allocations and update your filters when ARIN
-) does allocate space for use.
-)
-) (I dropped my laptop and have had no end of grief fixing it, which is my
-) poor excuse for not updating my two Internet Drafts before now.)
-)
-) On Tue, 2 Sep 2003, David Farmer wrote:
-)
-) > I had cause to take a look at RFC 3171 today.
-) >
-) > So, I have a multicast best common practice (BCP) question.
-) >
-) > Since 225.0.0.0 - 231.255.255.255 and 234.0.0.0 -
-) > 238.255.255.255 are reserved per section 2 and per section 11
-) > reserved space is not to be used by applications should any traffic
-) > destine to these locations be consider BOGON until assigned?
-) >
-) > Would it be a bad idea to block it?  Particularly at an administrative
-) > boundary.
-) >
-) > I don't see any discussion of reserved space in Bill Nickless'
-) > Internet Draft related to these issues.
-) >
-) > http://www.ietf.org/internet-drafts/draft-nickless-ipv4-mcast-
-) > unusable-02.txt
-) >
-) > What do others think?  I what problems do you see in doing
-) > something like this?
-) >
-) > For sure you would have to monitor any new IANA assignments
-) > and update the filters to allow any new assignments.  But this
-) > shouldn't be anymore work that any other BOGON filters.
-) >
-) > =================================================
-) > David Farmer                               Email:  

-) > Office of Information Technology
-) > University of Minnesota                    Phone:  612-626-0815
-) > 2218 University Ave SE                     Cell:   612-812-9952
-) > Minneapolis, MN 55414-3029         FAX:    612-624-4035
-) > =================================================
-) >
-) >
-)