Maximum acceptable IPv6 prefix in BGP table?
Hi, Looking at the BGP table I see stuff like this, not even /64: 2001:218:2000:5000::3a0/126 *[BGP/170] 2d 08:02:02, localpref 180 AS path: 12714 31133 3491 10026 I, validation-state: unverified > to 2a00:d18:fe03:fefe:a76d::1 via ae2.3386 As we can see this wasn't rejected by 3 AS-es. AFAIK, the minimum allocated space from RIRs is /48. Should we filter prefixes longer than this? -- Kind regards, CTO at *Foton Telecom CJSC (ru.fotontelecom)* Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB <http://as42861.peeringdb.com/>, Qrator <https://radar.qrator.net/as42861>, BGP.HE.NET <http://bgp.he.net/AS42861> http://ipv6actnow.org/
On 6/12/16 9:24 PM, Sergey wrote:
AFAIK, the minimum allocated space from RIRs is /48. Should we filter prefixes longer than this?
I do. look also at this case study of IPv6 /48 filtering https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-f... -- antonio
Thanks for the link! On 06/12/16 22:36, Antonio Prado wrote:
On 6/12/16 9:24 PM, Sergey wrote:
AFAIK, the minimum allocated space from RIRs is /48. Should we filter prefixes longer than this? I do.
look also at this case study of IPv6 /48 filtering
https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-f... -- antonio
-- Kind regards, CTO at *Foton Telecom CJSC (ru.fotontelecom)* Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB <http://as42861.peeringdb.com/>, Qrator <https://radar.qrator.net/as42861>, BGP.HE.NET <http://bgp.he.net/AS42861> http://ipv6actnow.org/
On 12/Jun/16 21:24, Sergey wrote:
Hi,
Looking at the BGP table I see stuff like this, not even /64:
2001:218:2000:5000::3a0/126 *[BGP/170] 2d 08:02:02, localpref 180 AS path: 12714 31133 3491 10026 I, validation-state: unverified > to 2a00:d18:fe03:fefe:a76d::1 via ae2.3386
As we can see this wasn't rejected by 3 AS-es.
AFAIK, the minimum allocated space from RIRs is /48. Should we filter prefixes longer than this?
Yes. A lot of service providers have poor filtering habits, accepting IPv4 prefixes as long as /32, IPv6 prefixes as long as /128, and reserved address space that should not be visible on the Internet. Do yourself a solid and filter. Mark.
On 12-06-16 22:06, Mark Tinka wrote:
A lot of service providers have poor filtering habits, accepting IPv4 prefixes as long as /32, IPv6 prefixes as long as /128, and reserved address space that should not be visible on the Internet.
Do yourself a solid and filter.
Mark.
Hello Mark, yes - but do remember that RIPE has allocated smaller blocks up to /29 in certain corners of the IPv4 space: 91/8: /29 193/8: /29 194/7: /29 Best regards, Paul Hoogsteder Meanie AS31019
On 6/13/16 10:47 PM, Paul Hoogsteder wrote:
yes - but do remember that RIPE has allocated smaller blocks up to /29 in certain corners of the IPv4 space:
it does make no difference when filtering out >24bit at bgp borders -- antonio
On 14-06-16 15:50, Antonio Prado wrote:
On 6/13/16 10:47 PM, Paul Hoogsteder wrote:
yes - but do remember that RIPE has allocated smaller blocks up to /29 in certain corners of the IPv4 space: it does make no difference when filtering out >24bit at bgp borders -- antonio
If you filter all of IPv4 at /24 then you can't reach certain destinations, so don't do that... It's easy to make exceptions up to /29 for the three /8 where these small announcements come from. Paul.
I am not receiving anything longer than /24, so I suppose my upstream are filtering for me. I never had any claim about some sites being unreachable. David Ponzone Direction Technique email: david.ponzone@ipeva.fr <mailto:david.ponzone@ipeva.fr> tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr <blocked::http://www.ipeva.fr/> - www.ipeva-studio.com <blocked::http://www.ipeva-studio.com/> Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
Le 14 juin 2016 à 18:23, Paul Hoogsteder <mailings@meanie.nl> a écrit :
On 14-06-16 15:50, Antonio Prado wrote:
On 6/13/16 10:47 PM, Paul Hoogsteder wrote:
yes - but do remember that RIPE has allocated smaller blocks up to /29 in certain corners of the IPv4 space: it does make no difference when filtering out >24bit at bgp borders -- antonio
If you filter all of IPv4 at /24 then you can't reach certain destinations, so don't do that... It's easy to make exceptions up to /29 for the three /8 where these small announcements come from.
Paul.
***************************************************************************** Le service MailSecure d'IPeva confirme l'absence de virus et de spam dans ce message. *****************************************************************************
On 6/14/16 6:23 PM, Paul Hoogsteder wrote:
If you filter all of IPv4 at /24 then you can't reach certain destinations, so don't do that...
currently I don't filter out prefixes >24bit, but if I ever needed to I could live with that. I would suddenly forget about 807 disaggregated IPv4 routes and 2 IPv6: according to my pov == IPv4 == /25: 54 /26: 51 /27: 147 /28: 208 /29: 347 SUM: 807 ========== == IPv6 == /64: 2 ========== -- antonio
On Tue, Jun 14, 2016, at 18:23, Paul Hoogsteder wrote:
If you filter all of IPv4 at /24 then you can't reach certain destinations, so don't do that... It's easy to make exceptions up to /29 for the three /8 where these small announcements come from.
Hi, The damage potential of accepting "up to /29 from 3 distinct /8" is huge. Please remember that one single /8 can contain up to 2 millions /29. If today's count of "/25 up to /29" is still quite low, this would open the way to hell on transfer market (which is self-limiting to /24), with possibility to go into "portable adresses" land (like in phone number portability). In IPv6 land situation is even worse (let's just hope we won't reach the 200-300K v6 routes very soon). -- Radu-Adrian FEURDEAN fr.ccs
On 15/Jun/16 16:58, Radu-Adrian FEURDEAN wrote:
Hi,
The damage potential of accepting "up to /29 from 3 distinct /8" is huge. Please remember that one single /8 can contain up to 2 millions /29. If today's count of "/25 up to /29" is still quite low, this would open the way to hell on transfer market (which is self-limiting to /24), with possibility to go into "portable adresses" land (like in phone number portability).
Exactly my reluctance to be liberal with anything longer than a /24 for IPv4. The FIB penalty has the potential to be huge. Mark.
On 15 June 2016 at 16:44, Mark Tinka <mark.tinka@seacom.mu> wrote:
The FIB penalty has the potential to be huge.
It's a shame there's not real interest in deploying a protocol like LISP that addresses the DFZ bloat problem. I know there are problems, it isn't a trivial deployment, but if the will was there, I'm sure challenges could be overcome. It would also allow providers to deploy IPv6 without having to have native IPv6 connectivity from their upstreams - as a dynamic tunnel protocol, LISP is better than a single tunnel to HE or whatever. Aled
On 15/Jun/16 19:56, Aled Morris wrote:
It would also allow providers to deploy IPv6 without having to have native IPv6 connectivity from their upstreams - as a dynamic tunnel protocol, LISP is better than a single tunnel to HE or whatever.
Perhaps, but I'd also not want to encourage a lack of interest in native IPv6. Mark.
On 13/Jun/16 22:47, Paul Hoogsteder wrote:
Hello Mark,
yes - but do remember that RIPE has allocated smaller blocks up to /29 in certain corners of the IPv4 space:
91/8: /29 193/8: /29 194/7: /29
I was not aware about that. However, RIR policy is typically separate from operator policy. I'm not sure whether operators are going to be accepting IPv4 routes longer than a /24. It was spoken about for a long time, as we all knew this day would come. But considering how expensive line cards are, I'm not overly optimistic it will happen (or happen quickly, widely). Mark.
On 15/06/16 05:35, Mark Tinka wrote:
I'm not sure whether operators are going to be accepting IPv4 routes longer than a /24. It was spoken about for a long time, as we all knew this day would come. But considering how expensive line cards are, I'm not overly optimistic it will happen (or happen quickly, widely).
We tried this out last year: https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-2... TL;DR - global usefulness of longer-than-/24 is still pretty low. Cheers Colin -- Colin Petrie Systems Engineer RIPE NCC
participants (9)
-
Aled Morris -
Antonio Prado -
Colin Petrie -
David Ponzone -
Mark Tinka -
Paul Hoogsteder -
Paul Hoogsteder -
Radu-Adrian FEURDEAN -
Sergey