Re: [sig-policy] prop-076: Requiring aggregation for IPv6 subsequent all
I'm quite interested by the proposal, but I'm actually wondering how to
make aggregation a condition of receiving further IPv6 allocations?
Every AS has traffic engineering needs, and that can't be achieved with
just a single announcement. :-(
Would it be worth augmenting the proposal by stating that "recipients of
further IPv6 allocations should attempt to minimise the deaggregation of
the allocation as much as is technically feasible".
Perhaps also put in a mention of the RIPE-399 document (shameless
advert, but the authors hope that the RIRs would include mention of the
document as part of any allocation) which encourages ISPs to aggregate
their announcements as much as possible and gives some of the reasons
why deaggregation is a problem.
Also, what would the penalty be if they don't aggregate? Withdraw the
allocation?
philip
--
Randy Bush said the following on 29/7/09 16:48 :
>
> ________________________________________________________________________
>
> prop-076-v001: Requiring aggregation for IPv6 subsequent allocations
> ________________________________________________________________________
>
>
> Authors: Tomohiro Fujisaki
> <fujisaki at syce dot net>
>
> Akira Nakagawa
> Toshio Tachibana
> Fuminori Tanizaki
>
> Version: 1
>
> Date: 29 July 2009
>
>
>
> 1. Introduction
> ----------------
>
> This is a proposal to make it a condition that LIRs aggregate subsequent
> IPv6 allocations that they receive from APNIC.
>
>
> 2. Summary of the current problem
> ----------------------------------
>
> The initial IPv6 address allocation criteria requires that LIRs:
>
> "Plan to provide IPv6 connectivity to organizations to which it will
> make assignments, by advertising that connectivity through its
> single aggregated address allocation."[1]
>
> However, there is no similar aggregation requirement in the criteria for
> subsequent allocations.
>
> For consistency, the routing requirement should be applied also in
> subsequent allocation criteria.
>
>
> 3. Situation in other RIRs
> ---------------------------
>
> LACNIC:
>
> The LACNIC community is currently discussing the following proposal
> to remove the requirement to announce an initial allocation as a
> single prefix in favour of announcing the prefix with the minimum
> possible level of disaggregation:
>
> 2007-01: Modifications to the IPv6 Prefix Initial Allocation Policy
>
> http://www.lacnic.net/documentos/politicas/LAC-2007-01v3-propuesta-en.pdf
>
>
> RIPE:
>
> The RIPE community is currently discussing the following proposal
> to
> remove routing requirements from IPv6 policy:
>
> 2009-06: Removing Routing Requirements from the IPv6 Address
> Allocation Policy
> http://www.ripe.net/ripe/policies/proposals/2009-06.html
>
>
> AfriNIC and ARIN initial IPv6 allocation criteria require a plan to
> aggregate, with no requirement for aggregation for subsequent allocation
> criteria. Neither RIR is has any proposal to modify these criteria.
>
> 4. Details
> -----------
>
> This is a proposal to add the requirement under the subsequent IPv6
> allocation criteria to aggregate subsequent IPv6 allocations as a single
> prefix.
>
>
> 5. Pros/Cons
> -------------
>
> 5.1 Advantages:
>
> - By describing clearly in the policy as a requirement, it may
> contribute to limiting routing expansion of the global IPv6
> routing table in the future.
>
>
> 5.2 Disadvantages:
>
> - This proposal may just be a nonbinding requirement.
>
> - APNIC policy may be more strict than other regions if other
> RIR communities decided to remove aggregation requirement from
> their policy.
>
>
> 6. Effect on APNIC members
> ---------------------------
>
> APNIC members will be required to aggregate subsequent allocations as a
> single prefix.
>
>
> 7. Effect on NIRs
> ------------------
>
> Same as above.
>
>
> 8. References
> --------------
>
> [1] See section 5.2.1, "IPv6 Address Allocation and Assignment Policy"
> http://www.apnic.net/ipv6-address-policy#5.2.1
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>