Subject: RE: mboned: Time for IANA allocations in admin scoped block?

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 5 May 2004 11:44:49 -0400

John,

I am counting on the fact that the 239/8 block is not controlled by the IANA. However, note that part of it *is*. The block 239.255.255.0 is not as RFC 3171 implies. Here's the quote from RFC 2365:

9. Structure and Use of a Scoped Region

   The high order /24 in every scoped region is reserved for relative
   assignments. A relative assignment is an integer offset from highest
   address in the scope and represents a 32-bit address (for IPv4). For
   example, in the Local Scope defined above, 239.255.255.0/24 is
   reserved for relative allocations. The de-facto relative assignment
   "0", (i.e., 239.255.255.255 in the Local Scope) currently exists for
   SAP [SAP]. The next relative assignment, "1", corresponds to the
   address 239.255.255.254 in the Local Scope. The rest of a scoped
   region below the reserved /24 is available for dynamic assignment
   (presumably by an address allocation protocol).

   In is important to note that a scope discovery protocol [MZAP] will
   have to be developed to make practical use of scopes other than the
   Local Scope. In addition, since any use of any administratively
   scoped region, including the Local Scope, requires dynamically
   assigned addressing, an Address Allocation Protocol (AAP) will need
   to be developed to make administrative scoping generally useful.

9.1. Relative Assignment Guidelines

   Requests for relative assignments should be directed to the IANA. The
   IANA will be advised by an area expert when making relative address
   assignments. The area expert will be appointed by the relevant Area
   Director.

   In general, relative addresses will be used only for bootstrapping to
   dynamic address assignments from within the scope.  As such, relative
   assignments should only be made to those services that cannot use a
   dynamic address assignment protocol to find the address used by that
   service within the desired scope, such as a dynamic address
   assignment service itself.

Does this meet your needs?

Bert

> -----Original Message-----
> From: John Kristoff [mailto:[email-masked]]
> 
> A new, newly discovered to us at least, application using an assigned
> group address in the Internetwork Control Block 
> (224.0.1.0/24) is going
> to require us to add another scoping, PIM and MSDP filter in order to
> prevent the application from spewing between our AS and others.
> 
> RFC 3171 states in 9.1. that 'no IANA assigment policy is 
> required' for
> the 239/8 block, but I wonder if that should be revised.  If there was
> a well-known or registered sub allocation in the admin scoped block it
> would be useful for many of the popular enterprise multicast 
> applications
> to get and use perhaps by default an assignment there.  It would also
> perhaps curtail the occasional whack-a-mole filtering that crops up
> every so often.
> 
> Would revising this allocation policy interest any others?
> 
> John

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: John Kristoff <[email-masked]>
Date: Wed, 5 May 2004 11:20:41 -0500

On Wed, 5 May 2004 11:44:49 -0400
"Manfredi, Albert E" <[email-masked]> wrote:

> I am counting on the fact that the 239/8 block is not controlled by
> the IANA.

I can appreciate that, however there appears to be space within it that
could be.  Note section 6.2.1. from RFC 2365.  It wouldn't have to be
within 239/8 space, but that seemed like the best place to me.

> However, note that part of it *is*. The block 239.255.255.0 is not as
> RFC 3171 implies. Here's the quote from RFC 2365:
[...]
> Does this meet your needs?

Hmmm... possibly, but I think we'd have to also pose that question to
the app developers.  It may be somewhat limiting.  I'd also prefer reading
something much simpler than what that text describes, I can say that much.
:-)  I'm interested in hearing what others have to say.  Is this a non-
issue for others?

John

---

From: [email-masked]
Date: Wed, 5 May 2004 12:31:20 -0700 (PDT)

Messing with 239/8 scares me. Since it is by definition scoped, there is 
no way to determine how it is being used inside every scoped domain on 
earth today. So to "allocate" some address within that range for a 
comercial network device could potentially result in address overlap in 
those scoped networks where the device gets deployed.

Greg

---

From: John Zwiebel <[email-masked]>
Date: Wed, 5 May 2004 11:24:56 -0700

OTOH, not providing a "home" (address space) for such an application
is leading to IANA assigning global address space which then leads
to the same problem you describe.

---

From: [email-masked]
Date: Wed, 5 May 2004 13:21:25 -0700 (PDT)

> to the same problem you describe.

Yes, it's clear the problem exists. Why then let it spread to additional 
address ranges? ;-)

Perhaps an IANA assigned range for scoped services would be the answer as 
long as it is not redefining already used scoped addresses.

Greg

---

From: [email-masked]
Date: Wed, 5 May 2004 13:29:18 -0700 (PDT)

Hmm.. yet another problem too be solved by SSM?

Don't meen to hijack your thread, but why is there still so much effort 
going into 'expanding' the use of ASM?

Greg

---

From: John Kristoff <[email-masked]>
Date: Wed, 5 May 2004 15:17:22 -0500

> those scoped networks where the device gets deployed.

According to RFC 2365 however:

6.2.1. Expansion of the IPv4 Organization Local Scope

   The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are
   unassigned and available for expansion of this space.  These ranges
   should be left unassigned until the 239.192.0.0/14 space is no longer
   sufficient. This is to allow for the possibility that future
   revisions of this document may define additional scopes on a scale
   larger than organizations.

While I understand that organizations may be using addresses throughout
239/8, the above says to me that they shouldn't be and it might have been
appropriate for the purpose I originally asked about.

John

---

From: Beau Williamson <[email-masked]>
Date: Wed, 05 May 2004 16:48:50 -0500

>long as it is not redefining already used scoped addresses.

That's what I was suggesting about 4 months ago and it didn't seem to fly 
within the discussion circles I happened be in at the time. (Don't recall 
who that was.  I've slept since then.)

Basically I proposed that we allocate a special IANA assigned range that 
would be carved up into a couple of "standard" scopes.  This was originally 
triggered by the fact we have all of these NASDAQ me-too requests for 
stock-ticker datafeeds that are not Internet wide but do extend to multiple 
NASDAQ customers, thus they are more of an extranet sort of scope (less 
than global but bigger than Enterprise/Org-local).  The same idea could be 
extended to smaller scopes withing the Enterprise.

The problem with trying to define the scopes within Enterprise is that this 
is typically something the network admin defines.  However, I think we can 
*at least* define an assigned-address Local Scope (ala 239.255.0.0) and 
Organization-Local scope.  I'd venture to say that most of the applications 
that would want an assigned address would normally tend to fall into the 
Local Scope dimensions.  Therefore, having only the two scopes, Local and 
Enterprise, might be sufficient.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Wed, 05 May 2004 16:57:40 -0500

John,

IMHO, the 239/8 address space should NOT be assigned in any way beyond what 
has already been defined in RFC 2365.  This space has for some time been 
considered to be private address space by many Enterprises and they have 
allocated their internal multicast address plans to use various portions of 
this space.  In the better cases, they have followed RFC 2365 for Admin 
Scoping and kept the Local Scope and Org-Local scope ranges intact and 
assigned them to applications accordingly.

Now if we were to suddenly say, "Hey, we're gonna let the IANA assign some 
of this space to applications", that would really screw things 
up.  However, I don't have any problem with defining NEW address ranges 
that are for Local Scope and Org-Local scope usage and that will be 
assigned by the IANA for these sort of applications.

Beau Williamson

---

From: John Kristoff <[email-masked]>
Date: Wed, 5 May 2004 18:04:39 -0500

On Wed, 05 May 2004 16:57:40 -0500

> has already been defined in RFC 2365.  This space has for some time been 
[...]
[
> assigned by the IANA for these sort of applications.

I don't have any particular love for the 239/8 space.  In a world where
everyone followed RFC 2365 to a tee that just seems like it might have
been the place for it.  If there is consensus that it is a worthwhile
idea, let's define some new space for scoped apps that we can easily
filter at various admin boundaries.

John

---

From: Pieter Liefooghe <[email-masked]>
Date: Thu, 06 May 2004 09:44:07 +0200

Hi,

Since we are talking here about Admin Scopes I have the following issue. 
We are planning on multicasting some Belgian Radio channels. One of the 
requirements of the Broadcaster is that the content be limited to 
Belgium (Because they only pay the royalties for distribution in 
Belgium). I looked for some admin scoping mechanism at the level of the 
country, but I couldn't find anything in any of the RFCs.

Did I miss some thing or do we need to "update" RFC 2365 with a new 
admin scope range which can be limited to a given country? (Maybe encode 
in the address range the telephone country code ?).

Pieter

--
dr. ir. Pieter Liefooghe

Doctor Assistant
Vrije Universiteit Brussel (VUB) INFO/TW
Tele.Com Group
Pleinlaan 2
1050 Brussel
Phone: +32-2-6292977
Fax: +32-2-6292870
[email-masked]

---

From: Dave Price <[email-masked]>
Date: Thu, 06 May 2004 10:07:24 +0100

Dear Pieter,

[email-masked] said:
> admin scope range which can be limited to a given country? (Maybe
> encode  in the address range the telephone country code ?).

surely in reality this is not achievable.   The way networks
are installed and interconnected, it is surely close to impossible
to guarentee to achieve this.  Imagine a company that builds
a network using its allocated IP addresses, but where that network
perhaps uses leased lines and so covers computers within many
countries.   I don't see how you could enforce things
so as to guarentee that the "Belgium radio channels"
do not leak out into another country...

Dave Price

---

From: Stig Venaas <[email-masked]>
Date: Thu, 6 May 2004 11:23:45 +0200

> been the place for it.  If there is consensus that it is a worthwhile

Yes, it seems the perfect place to me. There are several ranges inside
239/8 that should not be in use...

> filter at various admin boundaries.

If we stick to 239, one can at admin boundaries simply check for 239/8
(which I think many do already) rather than having to define boundary
checks for two disjoint ranges. It also makes RP-config and scoped BSR
a bit more complex.

Stig

---

From: "Marshall Eubanks" <[email-masked]>
Date: Thu, 06 May 2004 07:43:36 -0400

I would agree.

There is no scoping mechanism that will achieve this.
The only way to do it is to only peer with ISP's that
only have customers in the particular geographic region of interest, and to
get them not to transit your broadcasts.
Note that this means that customers of other ISP's in the region will
not be able to receive the broadcasts, unless you can can get their
ISP's to apply the appropriate filtering.

I know that the BBC is interested in this (sending multicasts only
to UK based ISP's); I wonder if this will be done in their upcoming Olympic
multicasts :

"But the BBC is a big Linx member, and it says multicasting will have a shot in the arm this summer,
because it has the rights to stream the Olympics in the UK."

from

http://www.vnunet.com/Analysis/1154937

Regards
Marshall Eubanks

On Thu, 06 May 2004 10:07:24 +0100

---

From: Pieter Liefooghe <[email-masked]>
Date: Thu, 06 May 2004 14:52:40 +0200

>ISP's to apply the appropriate filtering.

If I understand you correctly you state that there is no Admin scope 
that does this.
But if I can get all ISPs that support IP Multicast in Belgium to agree 
on not to forward internationally a certain address range, that this 
would be possible.

The question then remains, what address range do I use?
 From the previous posts I have the impression that the 239/8 range is 
not the best to use ?

If there existed such a Country Admin scope I think that - at least in a 
Belgian context - we could get it implemented by all IP Multicast 
enabled ISPs. This could be "enforced" either by for example the 
association of Belgian ISPs or by the national telecom 
regulator(/watchdog). I believe similar organizations exist in other 
countries.

A side question: How could one implement this in SSM ?
Does there exist something like Admin scoping in SSM or do I need to 
implement PIM Join filtering at the router near the source to prevent 
such a thing ?

>to UK based ISP's); I wonder if this will be done in their upcoming Olympic
Any info on the Channels on which we can tune into to watch these - 
unrestricted - channels? ;-)

Pieter

---

From: "Marshall Eubanks" <[email-masked]>
Date: Thu, 06 May 2004 09:20:04 -0400

On Thu, 06 May 2004 14:52:40 +0200
> If I understand you correctly you state that there is no Admin scope 

Correct.

> on not to forward internationally a certain address range, that this 

Yes.

>  From the previous posts I have the impression that the 239/8 range is 

No, I would not use 239/8, as that is not supposed to go outside the organization.

What you could do is get an ASN for Belgium multicasts (or use a Belgium ISP's ASN) -
then you could use that  Glop address space and announce that  it should
be filtered for ISP's / edge routers not in Belgium. 

> implement PIM Join filtering at the router near the source to prevent 

Well, if you implement this as a filter on traffic, ASM and SSM are the
same (for this). Of course, you should also filter MSDP the same way for ASM,
so SSM is actually easier (as usual).

> unrestricted - channels? ;-)

I just saw this interview yesterday - maybe Simon Lockhart could comment. 

> Pieter

Marshall

---

From: Beau Williamson <[email-masked]>
Date: Thu, 06 May 2004 09:49:26 -0500

>239/8 that should not be in use...

I'm sorry Stig, but I think this is a bad assumption.  All this talk about 
allocating and assigning address space inside of 239/8 for multicast is 
like letting the IANA allocate and assign some portion of the 10/8 address 
space for unicast.  It just doesn't make sense.

239/8 is Private multicast address space and I know of numerous Enterprises 
that have already carved up this space for their own usage.  Other than 
defining some standard scope ranges such as Local and Org-Local for the 
primary purpose of nailing down Scope Relative addresses, we need to leave 
this space alone.

Beau

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 6 May 2004 11:52:08 -0700 (PDT)

-)
-) [email-masked] said:
-)  Did I miss some thing or do we need to "update" RFC 2365 with a new
-)  admin scope range which can be limited to a given country? (Maybe
-)  encode  in the address range the telephone country code ?).
-)

I don't see how restricting traffic to a single country is a
multicast-specific issue- your problem is with IP not multicast.

If you can come up with a way to do this with unicast, there are generally
plenty of tools in the toolbox to achieve the same thing with multicast.

Times like this, it's best to ask "What would Unicast do?" (WWUD).  No
need to fill up mcast with a bunch of stuff that we don't even expect
unicast to be able to do.

-Lenny

---

From: Beau Williamson <[email-masked]>
Date: Thu, 06 May 2004 16:48:42 -0500

>unicast to be able to do.

I agree 100%.

If they don't want it to leave the country, then encrypt the traffic and 
solve the problem with some sort of key distribution technique that only 
sends keys to people located in Belgium.  (Of course that may be a trifle 
difficult to manage as well.  Then with the work being done in GeoPriv WG, 
maybe not.)

Beau

---

From: Stig Venaas <[email-masked]>
Date: Fri, 7 May 2004 08:22:04 +0200

Hi Beau

> space for unicast.  It just doesn't make sense.

My assumption is based on RFC 2365 and the fact that there are some
reserved ranges. It's not quite comparable to 10/8.

> that have already carved up this space for their own usage.  Other than 

I'm not really surprised if people have carved up entire 239/8 for their
entire use though. I have no idea what's been done out there.

> primary purpose of nailing down Scope Relative addresses, we need to leave 

I think this is doable. The problem I see is as I wrote, related to
more complex configurations with two disjoint ranges. The biggest
problem though is that people need to be made aware of this and update
their configurations.

Finally, I think it's good to have an admin scoped IANA block.

Stig

---

From: Beau Williamson <[email-masked]>
Date: Fri, 07 May 2004 10:54:51 -0500

>reserved ranges. It's not quite comparable to 10/8.

Actually, this is were we obviously have a minor disagreement.  We've been 
telling people new to multicast all along that 239/8 is equivalent to RFC 
1918 private multicast space.  If this isn't going to be treated as private 
multicast address space, then we would have to allocate another block that 
is. I don't think that is going to happen.

>Finally, I think it's good to have an admin scoped IANA block.

Good.  Maybe we need to put together a draft on this and see if it flys.

Beau

---

From: John Kristoff <[email-masked]>
Date: Mon, 10 May 2004 16:19:43 -0500

On Fri, 07 May 2004 10:54:51 -0500

> Good.  Maybe we need to put together a draft on this and see if it flys.

I haven't heard much opposition to the general idea so to move this
forward...

Would the "IANA Guidelines for IPv4 Multicast Address Assignments" draft
incorporate a new assignment or would it be better to create a new draft
specific to this idea and see where that goes?

239/8 may have problems, though I think it should still be considered.
If not there, I think the best alternative may be a 224.4/16 or equivalent
/16 space in 224/8.  Keeping it in 224/8 I think would be advantageous,
since most networks do not micro filter within the 224/8 by default.

Any additional thoughts, encouragement, resistance?

John

---

From: David Meyer <[email-masked]>
Date: Mon, 10 May 2004 15:35:34 -0700

>> Any additional thoughts, encouragement, resistance?

	All,

	I would like whatever we do here to have two attributes:
	First, let's not chew up more address space (what we have
	is extremely sparsely allocated). Second, let's see if we
	can't keep whatever we do within the general framework
	that we have now.

	Dave