Re: [sig-policy] prop-076: Requiring aggregation for IPv6 subsequent all
I for example have a /32... and I have equipment in 3 states of Australia and am looking at some offshore facilities. I have had to break up my /32 into 8 * /35's. We do not have interstate (or international) capacity to join our networks, and indeed in the different locations we use different providers.
I also have multiple customers who are in the same position, who even have facilities in the same city, but in different datacentes - i.e. Globalswitch and Equinix, but do not have the budgets to pay for inter-datacentre capacity, and again may use different upstreams in each location.
I am not suggesting we hand everyone thousands of /32's, but we do have an awful lot of ipv6, and if someone can justify it, then they should be able to get extra allocations without too much drama.
Many people automatically just suggest that you build interstate/international capacity to aggregate, or to use tunnels and so on, but I think these are really impractical suggestions.
When my company installs some equipment in Auckland, and I want v4 and v6 to multiple providers... what are the current recommendations on how best to accomplish this within my own /32?
Traffic engineering requirements are one thing... sometimes basic connectivity is the first thing that needs to be addressed.
--
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