[swinog] IPv6 de-aggregation
Hi SWINOG members, 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... ?? 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? Thanks in advance for your answers. John John Collins Eidgenössisches Finanzdepartement EFD Bundesamt für Informatik und Telekommunikation BIT Basisprodukte Telekommunikation Netzplanung und Engineering ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] IPv6 de-aggregation
I'm really not into IPv6, but routing Prefixes from an AS which has no peering or transit relationship with you has never been a good idea in the IPv4 world. I'd be also interested if that's still true in the IPv6 world. Kind regards, Viktor On 27.04.2012 10:09, john.coll...@bit.admin.ch wrote: Hi SWINOG members, 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... ?? 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? Thanks in advance for your answers. John John Collins Eidgenössisches Finanzdepartement EFD Bundesamt für Informatik und Telekommunikation BIT Basisprodukte Telekommunikation Netzplanung und Engineering ___ 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
Re: [swinog] IPv6 de-aggregation
On 2012-04-27 10:09 , john.coll...@bit.admin.ch wrote: Hi SWINOG members, we’re a LIR, we got a /32 from RIPE You requested a Provider Aggregated (PA) prefix. It is all in the name. So where did all the /48s come from ... also one or two /40s... ?? Those are Provider Independent (PI) prefixes, these tend to be shorter. Greets, Jeroen ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] IPv6 de-aggregation
Hoi John, Interesting situation! On Fri, Apr 27, 2012 at 10:09 AM, john.coll...@bit.admin.ch wrote: Hi SWINOG members, 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 /32 you received from RIPE is implicitly provider aggregatable and cannot be deaggregated. Your downstreams could announce their /40 or /48 to their peers, but filtering is pretty strict with IPv6 community, so it's not expected that they will obtain global visibility via their X Y Z service provider. /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... ?? There exists also provider independent IPv6 space -- it was contested for many years, but it is now possible at several RIRs to receive a /40 or /48 PI. 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? I would not advertise, but I would accept up to /40. Most upstreams I had dealt with accept only the PA block as a whole, ie no de-aggregation. -- Pim van Pelt p...@ipng.nl PBVP1-RIPE - http://www.ipng.nl/ ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
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
Re: [swinog] IPv6 de-aggregation
Hi John, In my company we will accept or advertise upto /48, also most of our upstreams will do the same. As for routing sub-allocations from a different AS some providers do that some don`t, as you said they will have to be convinced (but it`s not really good practice for PA space). Regards, Fadi On Fri, Apr 27, 2012 at 10:09 AM, john.coll...@bit.admin.ch wrote: Hi SWINOG members, ** ** 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... ?? ** ** 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? ** ** Thanks in advance for your answers. ** ** John ** ** John Collins ** ** Eidgenössisches Finanzdepartement EFD Bundesamt für Informatik und Telekommunikation BIT Basisprodukte Telekommunikation Netzplanung und Engineering ** ** ___ 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] 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
Re: [swinog] FW: IPv6 de-aggregation
On 27 Apr 2012, at 12:01, john.coll...@bit.admin.ch wrote: 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 See GRH (http://grh.sixxs.net) for that as it flags all announcements that do not match the allocated size, there are many of them, sometimes even /64s or even longer pop up. 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? You could tunnel from their border to you and be the provider for them that way. Also in your case it is likely that these networks are all in .ch, I would not be surprised if Swiss ISPs are willing to accept more specific non-export prefixes for these networks. 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? Filtering policy is always per network, it is their network after all, thus some do accept more specifics but many do not, which is why folks recommend to either not do it or at least have a covering route to make sure that filter still can reach it. Do note that if your prefix gets filtered at some but not all networks i is likely that paths are suboptimal as the where back in the 6bone days. As others mentioned be sure to register the appropriate route objects. I do tend to wonder how some networks receive a prefix if they have obviously not done due diligence on checking if they needed PA or PI and how their customers would fit in their network, especially given the point that one generally has to provide a proposed network plan so that one is going to request the right kind of prefix and size. Obviously that every LIR gets a /32 rule is not the best in the set especially when the LIR is not looking a what he actually need... Greets, Jeroen ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] FW: IPv6 de-aggregation
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
