Re: [sig-policy] prop-076: Requiring aggregation for IPv6 subsequent all
Hi Philip,
Thank you so much for your comments.
| 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. :-(
Do you mean many ASes who request additional address block will have
an intention to announce de-aggregated prefixes? I think a large
initial allocation will be same in this sense.
As a viewpoint of traffic engineering, I heard the proposal to remove
aggregation requirement from the initial allocation criteria in LACIC
mentioned this point as one main reason.
And we had related discussion in last JPOPM. The discussion summary
is, we understand there are many demands to announce de-aggregated
address block for traffic engineering, but still we should state this
point somewhere in the policy document, not in the supplement document
like guidelines.
| 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".
Thank you so much for drafting the elegant sentence! Do you think this
can be inserted as a 'subsequent allocation criteria' in the policy
document? (Then, I think 'should' should be changed to 'have to', and
it would be no big difference in this case.)
| 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.
Agreed.
| Also, what would the penalty be if they don't aggregate? Withdraw the
| allocation?
Yep, this is a big problem. Currently, no penalty in the case of initial
allocation, so, I personally think it should be same. However, if this
criteria is stated clearly in the policy document, ASes that have
problems to receive more address prefix can say no on the ground of
this policy.
| philip
| --
Yours Sincerely,
--
Tomohiro Fujisaki
|
|
| 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
| >
|
| * 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
|