Re: [sig-policy] prop-076: Requiring aggregation for IPv6 subsequent all
Hash: SHA1
Hi,
When APNIC (and other RIRs) don't guarantee the route ability of any
prefixes assigned to members and LIRs, I wonder how they can impose
conditions on how customers may or may not announce their prefixes.
I don't think this policy will be enforceable, though I do agree it's a
good objective.
- -gaurab
(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) wrote:
> 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
> |
> * 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkp7B+oACgkQSo7fU26F3X1MnQCg4BSuyoXbDaz41GhQrvJjrRJz
1G8AoMOpIDdS2spx8G+8xg1qwaiQItPN
=zyGb
-----END PGP SIGNATURE-----