Re: [sig-policy] prop-076: Requiring aggregation for IPv6 subsequent all
APNIC is a large region and there will be requirements for subsequent allocations in different geographic locations - which in many cases will not be able to be aggregated.
Example, my company may require IPv6 for NZ or Singapore or Japan... and we will source a local transit provider in those locations rather than building a global network for aggregation.
This policy, while its intent is a good one, does not meet the functional requirements of traffic engineering or allocations.
...Skeeve
--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego dot net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?
> -----Original Message-----
> From: sig-policy-bounces at lists dot apnic dot net [mailto:sig-policy-
> bounces at lists dot apnic dot net] On Behalf Of Philip Smith
> Sent: Thursday, 6 August 2009 3:23 PM
> To: Policy SIG
> Subject: Re: [sig-policy] prop-076: Requiring aggregation for IPv6
> subsequent allocations
>
> Hi Tomohiro, Akira, Toshio, and Fuminori,
>
> 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
> >
>
> * 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