Re: [sig-policy] prop-083: Alternative criteria for subsequentIPv6 alloc
When you refer to needs... 'needs' can be more than the sheer number of single addresses. Even APNIC in their utilisation measures based on a percentage relating to /56's. 'Needs' could be network design and other considerations.
As of the 10th of February, the requirement to aggregate your first ipv6 block has been removed. So anyone with a v6/32 has de-aggregate if they like. The issue here is community standards may make you un-routable to anyone utilising the common bogon filters.
I've already seen this in the /35 we announce out of our /32 where the visibility in the US has been some 75% (not sure what measurement RIPE use to measure this) - but fluctuates.
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 Terry Manderson
> Sent: Thursday, 4 February 2010 4:49 PM
> To: Policy SIG
> Subject: Re: [sig-policy] prop-083: Alternative criteria for
> subsequentIPv6 allocations
> On 03/02/2010, at 9:45 PM, Terence Zhang YH(CNNIC) wrote:
> > - Do you support or oppose this proposal?
> Not sure.. yet.
> > - Does this proposal solve a problem you are experiencing? If
> > tell the community about your situation.
> In past it did, and the sub-optimal solution was announce de-aggregates
> as well as the aggregate and hope that nearer entities listed to the
> more specifics and forwarded appropriately.
> > - Do you see any disadvantages in this proposal?
> here lies the quandary, do we:
> a) allow members with topologically separate networks to get
> additional ipv6 prefixes for each site, probably providing far in
> excess of what they need?
> b) remove any language about aggregation (for which many network
> filters' lives cling to) which, might I add, may not change the actual
> route-ability/reach of the de-aggregates?
> or both?
> knowing in both cases the net addition to the IPv6 routing system will
> be approximately the same (well "b" may be +1 for the aggregate) where
> all else (such as traffic engineering) remain the same.
> so which is seen as more attractive? conservation?, or aggregation?
> I further find in interesting that such a topic, separate sites that
> require separate prefixes and separate announcements from presumably
> (but not always) separate ASNs, is not covered in either the v4 or v6
> policies from what I could see.
> How is this handled now by the secretariat? Networking plans? case by
> case? ie "I have 5 sites across the asia pacific that are not, and
> never will be, connected."
> perhaps this points to an omission in prop-73 regarding initial
> thinking aloud:
> Consider the ISP with POPs in 3 locations that has a different
> upstream for each site. They have 2 x /24s and a single /21 IPv4
> allocations advertised with different ASNs. Current policy would
> probably provide them with a 'justification free' initial allocation of
> a /32. However if they de-aggregate they might find that the more
> specifics have no reach. And further the HD ratio would most likely
> prevent them from getting an additional v6 allocation/assignment.
> > - Is there anything in the proposal that is not clear?
> > - What changes could be made to this proposal to make it more
> > effective?
> not sure yet.
> * sig-policy: APNIC SIG on resource management policy
> sig-policy mailing list
> sig-policy at lists dot apnic dot net