Subject: [MBONED] addrarch: IANA allocations and assignments

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Dec 2006 13:30:47 +0200 (EET)

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),
     - 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?),
     - no approach seems to be needed for this (given SSM and v6 methods),
     - something else?

   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.

    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?

    Note that there is an expired draft that tried to do a bit of this,
    but it was never finished:
    http://tools.ietf.org/wg/mboned/draft-ietf-mboned-rfc3171bis/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Dec 2006 08:24:09 -0500

>    (Expected to happen in a couple of years.) GLOP is no

Or a couple of weeks, given that these will start appearing  on 1/1/2007

>     - no approach seems to be needed for this (given SSM and v6  

This to me is connected to eGLOP. If we need a mechanism, then why  
shouldn't it be eGLOP ? I think that makes
a lot more sense than trying to extend GLOP to long ASNs.

I think (given the inquiries I get about multicast address space)  
that any mechanism needs a solution
for people without ASNs (who also, as a practical matter, typically  
will not have PI address space either). eGLOP
would provide that, a prefix based scheme will not.

I have offered to assist anyone who wants an eGLOP space to get one;  
that offer still stands. Normally, I would take a
lack of response as a lack of demand, but I am definitely not sure of  
that in this case, as I actually have reason to
think that there is a demand.

>    has been a problem.

Indeed.

> It's true that there is still a lot of space

I think that this language seems OK - what exactly are you proposing ?

One thought I have had would be to make a block of the ad hoc block  
be "local"
and give out (quickly or even automatically) addresses for  
application developers from that block.

>    http://tools.ietf.org/wg/mboned/draft-ietf-mboned-rfc3171bis/

This should probably be revised and pushed through. My recollection  
is that this died from lack
of energy - were there specific issues ? I don't see any in my mail  
archives, which I think are complete...

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Dec 2006 08:24:09 -0500

Indeed.

Regards
Marshall

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Dec 2006 07:33:23 -0800

>       discouraged in Section 2.3),

	This is the current world, however.

>       this or is the option of reviving it in the future if there is

	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?

>    control block is almost full though, and should probably not be

	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.

>    respectively) more difficult to get, tone down the AD-HOC block

	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

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Dec 2006 07:33:23 -0800

What was this?

	Like what?

	--dmm

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Dec 2006 10:42:45 -0500

Hello;

>>       this or is the option of reviving it in the future if there is

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

> 	doesn't do IGMPv3" [or whatever]), and IPv6 multicast,

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

> 	don't know what that really means. That is just the

Is there a public list of these ?

Regards

Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Dec 2006 10:42:45 -0500

Hello;

Regards

Marshall

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Dec 2006 07:53:29 -0800

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

	Ah, thnx. For some reason that completely slipped (what's
	left of) my mind :-)

> Is there a public list of these ?

	http://www.iana.org/assignments/multicast-addresses

	-dmm

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Dec 2006 07:53:29 -0800

-dmm

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Dec 2006 11:04:55 -0500

Hello

>>>> AD review: IANA allocations and assignments

<snip>

> 	http://www.iana.org/assignments/multicast-addresses

OK, I count 18 allocations this year in the "ad hoc" block, including  
some
/24's, and 1 in the SAP block. (That assumes that they were all  
labeled with the date, which is unclear.)

If a RIR charged, oh, $ 250 (or 200 Euros), that would yield
3600 Euros or $ 4500. While not a gold rush, it's not nothing either.

So, I have to wonder if the RIR's couldn't be cajoled into taking  
this on. I will make inquiries.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Dec 2006 11:04:55 -0500

Hello

<snip>

Regards
Marshall

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 13:10:01 -0800

> 	doesn't do IGMPv3" [or whatever]), and IPv6 multicast,

Which is why if i would have any vote in this, there should be no relaxing
of static allocations of IPv4 multicast addresses. All cases i have
seen (and am still presented with in customers) could always use SSM, but
year after year customers delay it still referring to not being able to use
SSM because they need to support things like old host OS - instead of
pushing their vendors anywhere to support IETF standards SSM RFCs (especially
IGMPv3 of course).

As soon as there will be easier ways to hand out global IPv4 addresses,
the already pretty lame checking that the intended purpose is NOT an
SSM usage will get even more lame and we will get even more SSM applications
relying on interdomain PIM-SM.

Either the IETF has an opinion on interdomain SSM vs. interdomain ASM,
or we don't.

It would be fine though to hand out global scope IPv4 addresses to
applications that should be SSM if:
  a) There's charging for it (as Marshal explained)
     (which you have always refused as impractical though, arguing
      registries are too lame trying to charge money for multicast addresses)
  b) If it is justified by the usage of certain non-SSM compliant
     softare (eg: PC_OS x.y).
  c) If it has to be renewed every year.

b) and c) together would ensure deployments using SSM application
will not abuse global scope ASM forever.

It would also actually encourage moving to SSM if the address allocation
process causes the evaluation this is SSM, and they can have addresses
as long as they actually have a plan to move towards SSM.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 13:10:01 -0800

Cheers
    Toerless

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Dec 2006 13:54:03 -0800

> pushing their vendors anywhere to support IETF standards SSM RFCs (especially

	That is true.

> relying on interdomain PIM-SM.

	Well, I'll be more explict. Many of the addresses that
	are assigned to folks *are* SSM applications.

> Either the IETF has an opinion on interdomain SSM vs. interdomain ASM,

	Who is the IETF, exactly? And what authority do they (if
	you can locate "them") have over what is run on the
	Internet? Real questions that bear on your point.

>       registries are too lame trying to charge money for multicast addresses)

	The IETF, as I understand it, isn't really in the
	business of endorsing business models, so this one is not
	in the IETF domain (again, AFAICT).

>   c) If it has to be renewed every year.

	I understand your concern and reasoning, but you also
	realize that you just made a bunch of stuff up. That's
	fine, but other people make up other stuff, which is not
	necessarily consisitent with a)-c)

> will not abuse global scope ASM forever.
  
	Not sure about that, and BTW, "forever" is a long time. 
  
> as long as they actually have a plan to move towards SSM.

	I got the second part of the sentence, but didn't
	understand the first part.

	--dmm

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Dec 2006 13:54:03 -0800

That is true.

  

	--dmm

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 15:46:42 -0800

> 	Internet? Real questions that bear on your point.

In this particular case i guess "the IETF" is whoever has an impact
on determining IANA address allocation policy. Not sure if that's anyone
else but you, so i was just trying to use an as vague term, hoping at
least that anyone involved would also be in the IETF.

> 	in the IETF domain (again, AFAICT).

But IANA would also not hand out all unicast addresses.

Maybe i'll take it back: As soon as you hand out address space
to commercial entities like RIRs, they'll just handle it like any
other market good. Which isn't really what i'd like to see for IPv4
ASM adress space. On the other hand, it would still be much better than
simply opening up floodgates and later on wonderng why we not only have no
ASM addresses left, but so much ASM that's not working well and no SSM.

> 	realize that you just made a bunch of stuff up.

No, not entirely clear what you mean with "made up stuff" ?

> That's fine, but other people make up other stuff, which is not

2000 when we started SSM until today is half of eternity.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 15:46:42 -0800

Cheers
    Toerless

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Dec 2006 15:57:24 -0800

> 2000 when we started SSM until today is half of eternity.

	"in multicast years" :-)

	--dmm

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Dec 2006 15:57:24 -0800

"in multicast years" :-)

	--dmm