[address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs)

Hi,

Andy Davidson schrieb:
> 
> On 14 Apr 2009, at 13:57, Ingrid Wijte wrote:
> 
>> Multiple IPv6 /32 Allocations for LIRs
> 
> I do not support this proposal.  If an org (LIR or not) needs a separate 
> address block for routing reasons, then this should be catered for 
> through the PI policy.
> 
> PA should be aggregatable.  There's a clue in the name. ;-)

...soo... instead of announcing an aggregated /32 for say 200 customers 
you want 200 unaggregated say /48s in the routing table?

Requesting an ALLOCATION usually means, you want to ASSIGN Subnets of 
the allocation to 3rd parties (internal branches, customers....).

PI ..

a) ..forbids "sub-assignments"

b) ..means that you have to announce each PI prefix seperately even if 
you could aggregate it due to same routing policy

Your idea only works smoothly if you really only need ONE assignment.
(But then it would be the right thing to do, getting PI.)

But for the record:

I don't really support the proposal eiter since it's rather a workaround 
for the "i-can-only-annonce-a-/32-to-certain-parties"-problem mentioned 
earlier in the thread.
I do recognize the problem though, hust hopeing someone comes up with a 
nicer solution to this.

I have a similar problem where i have to descide upon continuing to 
announce /40s ("Sub-Allocations") of a /32 PA Allocation for seperate 
ASNs with "fallback tunnels" to the AS announcing the /32 (so i don't 
loose traffic from providers doing strict-RIR-filtering) - or to get ~50 
PI assignments (for now, more in the future) and  announce each of those 
seperately since i can't aggregate that.
I think i have to roll dice, both is somewhat ridiculous in the end<...>
And no, none of those ASNs wants to become a LIR in their own right due 
to multiple reasons beyond the scope of this mail (let's call it "reality").

-- 
========================================================================
= Sascha Lenz                  SLZ-RIPE          slz at baycix.de         =
= Network Design & Operations                                          =
= BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
========================================================================