Re: [MBONED] addrarch: IANA assignment policies and eGLOP

[Marshall Eubanks <[e-mail]>]

Hello;

On Jan 19, 2007, at 3:04 AM, Pekka Savola wrote:

> I'll try to summarize the discussion that related to IANA  
> assignment policies and eGLOP.
>
> DaveM mentioned that RIRs haven't been very interested in taking up  
> this assignment task for various reasons.  Marshall said he'd try  
> to get this started.  What is the status of this effort?
>

Here is a draft of a submission for Apnic. Comments, tomatoes, etc.,  
welcomed. This is based on the form at

http://www.apnic.net/cgi-bin/policy_proposal.pl

which is why it is a little choppy.

Marshall

SIG for discussion:
Nominate the SIG you think is most appropriate for discussing this  
proposal.

Policy

Title of proposal:

eGLOP Multicast Address Assignments

Introduction:

RFC 2770 [now replaced by RFC 3180 / BCP 53] set up an automatic  
"GLOP" multicast address assignment in 233/8 based on Autonomous  
System Numbers (ASNs). The mechanism that was set up in RFC 318 for  
extending GLOP assignments, known as eGLOP, envisioned the assignment  
of multicast addresses by RIRs from the portion of the 233/8 space  
corresponding to the RFC 1930 private address space. This mechanism  
has never been used, but its use is now imperative due to both an  
increased interest in multicast address assignments to support IPTV  
and the adopted proposals to assign 4-octet ASNs, which do not have  
GLOP assignments. This proposal is for the assignment of Multicast  
addesses by the APNIC RIR; equivalent proposals will be sent to the  
other RIRs for consideration in due course.

Summary of the current problem:

RFC 2770 and RFC 3180 describe a policy for use of the class D  
address space
by mapping 16 bits of Autonomous System number (AS) into the middle two
octets of 233/8 to yield a /24, which is automatically assigned to  
that ASN.  While this technique has been
successful, the assignments are inefficient in those cases in which a
/24 is too small or the user doesn't have its own AS, and it does not  
work for 4-octet AS number
extension scheme.

RFC 3138 expanded on RFC 2770 to allow routing registries to assign  
multicast addresses from the GLOP space corresponding to the RFC 1930  
private AS space; referred to as the EGLOP (Extended GLOP) address  
space.

The failure to instantiate RFC 3138 assignments had lead to a  
situation where some multicast users feel like they cannot obtain  
addresses, while others apply directly to IANA, with there being at  
least 24 IANA approved applications in 2006. The current situations  
in inequitable and inefficient and there is no reason not to apply  
the mechanism set up in RFC 3138.

Situation in other RIRs:

We intend to make comparable proposals to the ARIN, LACNIC, and RIPE  
NCCs in due course. This submission was motivated by the date of the  
next APNIC meeting.

Details of your proposal:

RFC 3138 allocated 233.252/14 to eGLOP. The RFC further says that

    Globally scoped IPv4 multicast addresses in the EGLOP space are
    assigned by a Regional Registry (RIR).  An applicant MUST, as per
    [IANA], show that the request cannot be satisfied using
    Administratively Scoped addressing [RFC2365], GLOP addressing
    [RFC2770], or SSM.  The fine-grained assignment policy is left to  
the
    assigning RIR.

[IANA] is http://www.iana.org/assignments/multicast-addresses

We propose that each RIR be allocated an initial /20 from this  
address range, and allocate by default /28's to proposers (16  
addresses as Multicast address are not subject to CIDR default  
restrictions), subject to the above criteria, and that the RIR assign  
more addresses based on demonstrated need.

Note that Multicast addresses are not subject to classless  
aggregation and address blocks as small as a /32 can be usefully  
assigned.

Advantages and disadvantages of adopting the proposed policy:

The proposed policy should facilitate multicast deployment. The  
current mechanism for non-GLOP multicast deployment involves  
requesting an assignment from IANA, which has no ability to evaluate  
these requests and relies on the IANA Multicast Expert appointed by  
the IESG (currently David Meyer). This process is inefficient,  
inequitable (as this policy route is not widely known), encourages  
the use of "rouge" self-assignments, and discourages application  
developers and service providers from developing and deploying  
multicast.

The only disadvantage that we can see from the proposed policy is  
that the RIR's will have to set up and execute mechanisms to  
implement it.

Effect on APNIC members:

We feel that adoption of this proposal will help to make multicast  
deployment more widespread, and should be of benefit to APNIC members  
adopting Multicast for video distribution on the Internet. It will  
have no effect on APNIC members who do not deploy Multicast.


Effect on NIRs:




> DaveM seemed to believe that whenever a requestor comes to IANA and  
> says (s)he wants X number of addresses, the request cannot (in  
> practice) be denied.  Toerless [and yours truly] at least want a  
> mechanism to discourage unnecessary use of IANA assignments.  A  
> change in IANA policies and/or guidelines could create a backing to  
> also deny requests if need be. (In the end, it might be that the  
> requestor would just invent an address space to use if denied, but  
> whether that matters is an open issue.)
>
> There was some aside discussion about doing assignments inside the  
> current SSM address range, but the conclusion seemed to be it's not  
> worth it.
>
> Beau suggested that IANA should stop making static assignments for  
> [typical, unspecified] protocols, and instead should give a GLOP  
> address if applicable or from eGLOP block if not.  Lenny supported  
> this and also supported resurrecting the IPv4 unicast-prefix  
> mapping draft (separate thread on this).
>
> One point that has been discussed before was that if eGLOP  
> assignments were to be made for a fee, there would be no incentive  
> for anyone to use that service unless IANA stopped providing  
> multicast addresses for those customers.
>
> DaveM preferred to have IANA guidelines and policies in some other  
> document [one was started and has died off several times] rather  
> than this one.
>
> Questions to the group (first one mainly to Marshall):
>
>  1) Marshall's initiative on getting eGLOP started.  What was it
>     exactly and what's the status?
>
>  2) Is it even possible for IANA (if instructed by the IETF) to stop
>     making multicast assignments (or tighten the policy) on specific
>     ranges?
>
>  3) If we end up using eGLOP, how should that change IANA's
>     traditional assignments (if answer is 'yes' to 2)?
>
>  4) Should we try to defer all the questions about IANA policies,
>     eGLOP, etc. to some other document in order to get this one
>     finished (and this one being vague on the topic)?
>
> -- 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mboned


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