Subject: RE: mboned: I-D ACTION:draft-ietf-mboned-addrdisc-problems-00.txt

From: Pekka Savola <[email-masked]>
Date: Mon, 4 Apr 2005 23:44:26 +0300 (EEST)

On Tue, 29 Mar 2005, Beau Williamson wrote:
>> As far as I can tell from RFC 2365, the IANA has access to 256 addresses in 
>> the 239/8 range, and I'm not using those. Perhaps that was our 
>> misunderstanding?
>
> Yes, I believe you misunderstand Scope Relative addresses.  This are the top 
> 256 addresses of any arbitrary scope defined within the 239/8 address space. 
> There is only one well-defined scope and that is the Site-Local 239.255/16 
> space which is considered the smallest scope possible.  This was 
> (well)defined so that applications like MADCAP would have a well-known 
> starting address in the smallest scope in the organization.

Using this as a stepping stone to try to move this discussion 
forward..

My reading of RFC2365 is pretty clear that the sites/enterprises that 
use any other part of 239/8 rather than just 239.192.0.0/14 or
239.25[345].0.0/16 are basically violating the RFC.  IMHO, this is 
pretty clear in 6.2.1:

    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.

In particular "allow for the possibility ..." clearly states that the 
intent is NOT to use these addresses, so that in future we could carve 
out blocks from there if we wanted (exactly like a proposal was to do 
now).

However, in practice ... many sites have made their own plans 
regardless of this prohibition (instead of using 239.192.0.0/14 -- 
that would have allowed about 60 /24's worth of scoping!).  (We 
certainly have used 239.1.2.3 ourself for an app but that's it.) 
Whether or not it would be even possible to use the lower bits if we 
wanted to is a question mark.

What is a bit less clear is which set of those addresses (per scope) 
are to be assigned by IANA (called confusingly scope-relative 
addresses in some contexts).  This is what RFC 2365 section 9.1 
describes, and http://www.iana.org/assignments/multicast-addresses 
lists.  These are at the moment restricted to about 256 diffferent 
apps; this may or may not be sufficient.

But aside from that as it seems that taking bits out of 239/8 might be 
a non-starter.

Two alternatives:
  - use a non-239/8 space for these assignments (reason: just to make 
it easier to block them in MSDP)
  - just forget about it completely, pointing out that RFC 2365 already 
has a policy allowing obtaining scoped multicast addresses (however, 
this is limited to 8 bits per scope, so this might not be sufficient 
for long term)

Thoughts?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: "Marshall Eubanks" <[email-masked]>
Date: Mon, 04 Apr 2005 18:02:21 -0400

On Mon, 4 Apr 2005 23:44:26 +0300 (EEST)
> this is limited to 8 bits per scope, so this might not be sufficient 

Carve out a /24 with potential for expansion for a first come, first serve
"swamp" for application developers. I would suggest 239.64.0.0/24

If enterprise customers complain, point 
them to the RFC2365, and tell them that they shouldn't using reserved space.

If no one bites, give the space back.

Regards
Marshall

P.S. I stand by my offer to assist the first entity in need
get e-GLOP space through a registry.

---

From: Beau Williamson <[email-masked]>
Date: Mon, 04 Apr 2005 17:23:36 -0500

At 4/4/2005 03:44 PM, Pekka Savola wrote:

>Using this as a stepping stone to try to move this discussion forward..

Great. :)

>My reading of RFC2365 is pretty clear that the sites/enterprises that use 
>any other part of 239/8 rather than just 239.192.0.0/14 or
>239.25[345].0.0/16 are basically violating the RFC.  IMHO, this is pretty 
>clear in 6.2.1:
>

I don't think it's quite that clear.  See the following map that outlines 
the space defined in RFC 2365 (including Scope Relative ranges for each 
scope) for the remaining comments and discussions.

    239.255.255.255  +-------------------------+
                     |       Local Scope       |
      239.255.255.0  |      Scope Relative     |
    239.255.254.255  +-------------------------+
                     |                         |
                     |       Local Scope       |
        239.255.0.0  |                         |
    239.254.255.255  +-------------------------+
                     |                         |
                     |       Local Scope       |
                     |     Expansion Range     |
        239.253.0.0  |                         |
    239.252.255.255  +-------------------------+
                     |                         |
                     |                         |
                     |                         |
                     |        UNASSIGNED       |
                     |                         |
                     |                         |
        239.196.0.0  |                         |
    239.195.255.255  +-------------------------+
                     |     Org-Local Scope     |
      239.195.255.0  |      Scope Relative     |
    239.194.255.255  +-------------------------+
                     |                         |
                     |                         |
                     |                         |
                     |     Org-Local Scope     |
                     |                         |
                     |                         |
        239.192.0.0  |                         |
    239.191.255.255  +-------------------------+
                     |                         |
                     |                         |
                     |                         |
                     |     Org-Local Scope     |
                     |     Expansion Range     |
                     |                         |
                     |                         |
                     |                         |
          239.0.0.0  |                         |
                     +-------------------------+

>intent is NOT to use these addresses, so that in future we could carve out 
>blocks from there if we wanted (exactly like a proposal was to do now).

One the other hand, it clearly states that the Org-Local Expansion space 
can be used if the Org-Local space fills up.  This tells me that the intent 
is that Enterprises can make use of the entire 239.0.0.0 - 239.195.255.255 
space for their private Org-Local space.  If they want to carve up this 
space into scopes of other sizes, then they are free to do so.

The same statement is applicable for the Local Scope in that 239.254/16 and 
239.253/16 is the expansion space for the Local Scope should you run out of 
room for the Local Scope.  This tells me that the intent is Enterprises can 
make use of the entire 239.253.0.0 - 239.255.255.255 space for their 
private Local space.

The end result is that the only space not implicitly defined in RFC 2365 is 
the range of addresses between 239.196.0.0 and 239.251.255.255.

>However, in practice ... many sites have made their own plans regardless 
>of this prohibition (instead of using 239.192.0.0/14 -- that would have 
>allowed about 60 /24's worth of scoping!).  (We certainly have used 
>239.1.2.3 ourself for an app but that's it.) Whether or not it would be 
>even possible to use the lower bits if we wanted to is a question mark.

I think the only thing that can clearly be stated about RFC 2365 is that it 
is quite unclear as to how this space can be carved up for private use 
especially when scopes between the size of Local (smallest possible) and 
Org-Local (largest possible within the Org or Enterprise).

I think the primary goal that Dave Meyer had when this was written (and 
we've had some conversations on this) was to provide at least two 
well-known scope ranges (Local and Org-Local) that applications could 
always COUNT on existing within the Enterprise network.  (I'm sure Dave 
will correct me if I misspeak.)

>What is a bit less clear is which set of those addresses (per scope) are 
>to be assigned by IANA (called confusingly scope-relative addresses in 
>some contexts).  This is what RFC 2365 section 9.1 describes, and 
>http://www.iana.org/assignments/multicast-addresses lists.  These are at 
>the moment restricted to about 256 diffferent apps; this may or may not be 
>sufficient.

I personally don't think its confusing at all. I think it is quite clear in 
section 9 that one of the primary tenets of RFC 2365 that should be 
observed is that the two Scope Relative ranges of the Org-Local Scope and 
the Local Scope should be left alone for Scope Relative addressing in these 
two scopes.

This gives applications two blocks of well-known address, one Local and the 
other Org-Local.  Thus MZAP always knows that it can count on 
239.255.255.254 being the multicast address for Local Scope MZAP and 
239.195.255.254 being the multicast address for Org-Local Scope MZAP.

>But aside from that as it seems that taking bits out of 239/8 might be a 
>non-starter.

I agrree. Other than the assigning addresses out of the UNASSIGNED section 
(see address map), all other addresses already assigned.  However, in 
reality, I agree that assigning any addresses out of the 239/8 space (which 
is pretty well considered to be "private" address space) is a non-starter.

>Two alternatives:
>  - use a non-239/8 space for these assignments (reason: just to make it 
> easier to block them in MSDP)

Well I don't think that's really what we want.  The reason I say this is 
that if a developer hard codes this address into an application, it screws 
up the Enterprise admin who has decided that this application should ONLY 
work within his/her Enterprise network in scope X whose configured 
boundaries are multicast ranges 239.mumble - 239.fratz.  Having hard coded 
addresses in the application requires an increasing number of exceptions to 
be added to the scope range ACLs. This results in multicast boundary ACL's 
that get out of hand.

No, IMHO, the proper way is to give the Enterprise operator control of what 
multicast address an application is to use based on the desired 
scope.  That means no hard coded addresses assigned to applications with 
very few exceptions.

> has a policy allowing obtaining scoped multicast addresses (however, this 
> is limited to 8 bits per scope, so this might not be sufficient for long term)

But it still doesn't solve the problem because the application doesn't know 
ahead of time what the scopes are that the Enterprise admin has defined and 
within which one he/she wants the app to run in.  Thus, the application 
still can't use hard coded addresses and some other 
"run-time"/"deploy-time" address assignment/discovery method must be employed.

So regardless of what we do, we STILL need this light-weight address 
discovery protocol so we can encourage app developers to do the right thing 
and NOT use hard coded addresses.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Mon, 04 Apr 2005 17:29:43 -0500

>"swamp" for application developers. I would suggest 239.64.0.0/24

Sorry, but that's just a non-starter for two reasons:

1) That range has already been reserved for Enterprises to "Expand" the 
Org-Local scope "should the normal address space of 239.192/14 be 
insufficient".

2) It's still inside of the 239/8 PRIVATE address space.  Would you 
consider allocating Unicast addresses from net 10???  That's crazy. 
Allocating addresses from 239/8 makes about as much sense.

>them to the RFC2365, and tell them that they shouldn't using reserved space.

They are NOT using reserved space. They are using the EXPANSION space for 
the Org-local space.

Beau

---

From: John Kristoff <[email-masked]>
Date: Mon, 4 Apr 2005 21:27:58 -0500

> Thoughts?

After the initial volley being lead by your note I think you have
more good feedback and material with which to update your draft with.
I haven't really seen a whole lot just change right now, just some
good comments and clarifications.  If you want some help with the
text let me know and I can update what I sent last time.

John