[GLOBAL-V6] Comments on AP Consensus

[Carlos Friacas <cfriacas@fccn.pt>]

Post, 11/03/2002, Takashi Arano
-------------------------------
> Hi,
>
> Policy amendment was proposed in the APNIC Address Policy SIG
> from the global IPv6 policy editorial team and the current
> draft (dated 12/22) with this amendment was supported
> as AP region consensus.
>
> In the meeting, three issues were identified through efforts
> to summarize continuing discussion in RIPE41 and the global
> mailing list. Those were;
>
> 1) Initial allocation criteria
> 2) Do we continue to use HD-Ratio?
> 3) Are requirements of LIR's sub-allocation appropriate?
>
> Regarding 1), the editorial team proposed an amendment
> which would replace Section 5.2.1 of the original draft.
> See the below in this mail.
>
> We spent one and a half hour for discussion.
> During discussion, more issues other than these were raised
> but finally they were withdrawn, considering the priority
> for moving forward.
>
> To the end, each of the issues was supported by the show of hands.
> More clearly,
>
> Consensus 1) the amendment below was accepted
> Consensus 2) Yes, HD-ratio should be used as the draft shows
> Consensus 3) Yes, requirements in the draft are okay.
>
> Finally, I, as the chair, asked participants for voting
> the whole draft with the amendment and found this reached
> the consensus of AP region consensus.
>
> I hope quick resolution with good discussion
> in both ARIN and RIPE meeting (of course as well as in
> the mailing list) would be appreciated.
>
> Please review the following and give any feedback. Thanks.
>
> Regards,
> Takashi Arano
> ---------------------------------
>
>
> Start of proposed text
> ================
>
> 5.2.1.  Initial allocation criteria
>
> In order to reduce address space fragmentation and increase the
> likelyhood that routes can be aggregated, end sites should obtain
> address space from their connectivity providers as opposed to directly
> from RIR/NIRs. Having RIR/NIRs assign address space directly to end
> sites in general is known to lead to unscalable routing, since the
> routes to those end sites will not aggregate. Thus, allocations of
> large address blocks (i.e., much larger than /48s) are made to
> organizations that assign /48s to organizations other than itself, and
> also provide connectivity for those organizations. Specifically:
>
> - Organizations requesting address space must be an LIR. (see Section
>    2.6).
>
> - Organizations requesting address space must not be end sites.

These two "rules" imply that Provider Independent networks shall not exist ???
IMHO, this is a good thing!

But this last one will not have a great effect... i think it is rather
easy for a medium/large organization to "forge" end sites...
Another "workaround" can be made by "ficticious-merging": Little company
A, and Little company B "together", stating Little company B is the end
user...

Is in any way dangerous replacing these last two, or adding:
"- Having an ASN" ?



> - Organizations requesting address space will provide connectivity for
>    the organizations it has assigned /48s to by advertising such
>    connectivity through the single aggregate allocated to that
>    organization.

Hmmm... this is the logical thing, seems to me like a compromise, but IMHO
it is not a "prerequisite" to get an alloc.



> - Organizations requesting address space have a plan for assigning
>    address space (e.g., /48s) to other organizations, with the number
>    of such assignments likely to result in at least 200 such
>    assignments over the next two years.

Having a plan is good, but going on a round number doesnt seem right...
This 200 number is not right for example (and also unfair) to European and
small countries NREN's!
Some small countries NREN's have a lot less than 50 "end-points", so would
it be acceptable to make a plan assigning a /46 (4x/48) to each end-point?



> - Organizations who are granted initial allocations, but after two
>    years no longer satisfy the requirements above, are subject to
>    having their allocations revoked.

Hmmm... this is rather dangerous, but somehow it also reflects my own
view, in a general way.
Why? Because i think this is an issue that fails in the v4 World: getting
free space back to the "free address" status pool.
LIRs close, LIRs stop paying, and in reality things are not "reversed", or
in some way at least audited. So my point is: Nice to have the rule, but
it will serve for something? I have real doubts about it...

My case against not enforcing the return of unnused/illegaly used
addresses/ASNs is that this way we (in the v4 World) are using a "SUM"
paradigm, and not a "MAX" paradigm.
This might not be an extremely good example, but if we need an address
scheme to identify each and every person *alive* in the globe, we need a
range from 1 to <nr of alive people this moment>. And this last number
may increase if borns>deaths. On the other side we dont need a scheme
that addresses all the people that already died, which would result on a
larger range.

So this "rule" seems very nice on the "recycling" intention, but what is
really needed are some ways/"rules" to really enforce it. :-)
[ Ecologycal addressing manifesto end, :-) ]



> ================
> End proposed text
>
> Note: Section 2.6 defines LIR as follows:
>
> 2.6.  Local Internet Registry (LIR)
>
>     A Local Internet Registry (LIR) is an IR that primarily assigns
>     address space to the users of the network services that it provides.
>     LIRs are generally ISPs, whose customers are primarily end users and
>     possibly other ISPs.
>
> -------------------------------------------

Question: One can be a LIR without having an ASN ?


My 3 cents...


Regards,

./Carlos
                                                          "Networking is fun!"
-------------------                                        http://www.fccn.pt
<cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup
F.C.C.N. - Fundacao para a Computacao Cientifica Nacional  fax: +351 218472167





-
- This list (global-v6) is handled by majordomo@lists.apnic.net