as far as I understand, renumbering is currently the common strategy for PA blocks.
here you may find some highlights: 
http://yorickdowne.wordpress.com/2010/01/15/ipv6-addressing-renumbering/

The general idea is to design the enterprise network in such a way that

renumbering is easy and low-cost.


I guess for companies which demand a few dozens of routed LAN's (due to

geography or security requirements), it's worth trying to become LIR by themselves.






----- Original Message -----
> From: "John.Collins@BIT...." <John.Collins@BIT....>
> To: swinog@list...
> Cc:
> Sent: Friday, April 27, 2012 12:01 PM
> Subject: [swinog] FW:  IPv6 de-aggregation
>
> Hi again Swinog members,
>
> Many thanks for the many informative replies. 
>
> Some or maybe most (random sample) of the /48s in the routing table are not PIs
> - needs further analysis.
>
> Regarding the PI suggestion, what do we do with customers who will never have an
> own AS and will never be dual homed?   Do they have to "resign" to
> using Provider space - with renumbering when they change Provider.  Or is there
> another way?
>
> I know of this document which seems to tolerate /48 prefix propagation (even if
> the case described is not exactly our case)
> http://www.ripe.net/ripe/docs/ripe-532.   Does this document mean anything to
> SPs out there?
>
> Thanks again
>
> John
>
>
>
>
>
> -----Original Message-----
> From: swinog-bounces@list... [mailto:swinog-bounces@list...] On
> Behalf Of Bernhard Schmidt
> Sent: Freitag, 27. April 2012 10:39
> To: swinog@list...
> Subject: Re: [swinog] IPv6 de-aggregation
>
> On 27.04.2012 10:09, John.Collins@BIT.... wrote:
>
> Hello,
>
>>  we're a LIR, we got a /32 from RIPE and we want to allocate /40s and
>>  /48s to customers. Only snag is that the customers will not have their
>>  Internet feed from us but from any Service Provider of their choice. The
>>  customers will have to convince their SPs (X, Y, Z) to route these
> "non
>>  X,Y,Z" or "foreign" prefixes. We're getting a lot of
> "raised eyebrows"
>>  about this. What's this about prefixes longer that /32 not being
>>  propagated? When I look at the IPv6 table I see:
>>
>>  IPv6 Routing Table Summary - 8625 entries
>>
>>  5 local, 2 connected, 3 static, 0 RIP, 8615 BGP 0 IS-IS, 0 OSPF
>>
>>  Number of prefixes:
>>
>>  /0: 1, /8: 1, /10: 1, /12: 1, /16: 1, /19: 2, /20: 5, /21: 3
>>
>>  /22: 5, /23: 5, /24: 7, /25: 4, /26: 9, /27: 10, /28: 31, /29: 19
>>
>>  /30: 15, /31: 13, /32: 4049, /33: 97, /34: 87, /35: 93, /36: 242, /37: 7
>>
>>  /38: 50, /39: 22, /40: 385, /41: 12, /42: 18, /43: 34, /44: 151, /45: 15
>>
>>  /46: 75, /47: 45, /48: 3006, /49: 3, /50: 1, /52: 5, /56: 9, /64: 40
>>
>>  /126: 1, /128: 45
>>
>>  So where did all the /48s come from ... also one or two /40s... ??
>
> Deaggregation and PIv6 prefixes (which are /48s usually).
>
>>  What do you think about this? If you're a SP would you route the /48s
> or
>>  /40s from the customers? What about your upstream peers?
>
> If you were my paying customer insisting on getting a /40 or /48 from
> your PA space announced I would of course do so. But that's only half of
> the story, because others have to accept that. And there will be
> networks that don't.
>
> There is no real consensus on if and how much deaggregation from PA
> space should be allowed. As long as that is not there, we are filtering
>> /36 from PA space. And I know others do, too.
>
> If you absolutely need to do this, make sure you announce the covering
> /32 somewhere. And make sure you do everything possible to prove the
> validity of those routes (proper route6-objects, maybe RPKI ROA, ...)
>
> Bernhard
>
>
> _______________________________________________
> swinog mailing list
> swinog@list...
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>
>
> _______________________________________________
> swinog mailing list
> swinog@list...
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>


_______________________________________________
swinog mailing list
swinog@list...
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog