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.coll...@bit.admin.ch" <john.coll...@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. Does this document mean anything to > SPs out there? > > Thanks again > > John > > > > > > -----Original Message----- > From: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@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.coll...@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 > _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
