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.admin.ch" John.Collins@BIT.admin.ch To: swinog@lists.swinog.ch 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.%C2%A0 Does this document mean anything to SPs out there?
Thanks again
John
-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Bernhard Schmidt Sent: Freitag, 27. April 2012 10:39 To: swinog@lists.swinog.ch Subject: Re: [swinog] IPv6 de-aggregation
On 27.04.2012 10:09, John.Collins@BIT.admin.ch 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@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog