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@baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================