Mailing List Archive

1 2  View All
Re: CloudFlare IPv6 BGP announcements - WTF guys? [ In reply to ]
On Jul 17, 2012, at 9:09 AM, Phil Mayers wrote:

> On 07/17/2012 01:53 PM, Jared Mauch wrote:
>
>> off my lawn/routing table" but there are real costs of these entries
>> in the RIB + FIB. I would rather not see a model where you're billed
>> based on your pollution,
>
> Question: why not?
>
> Genuinely curious here; charging a customer a scaled fee for number of routes injected seems like a pretty reasonable thing to me. What am I missing?

Should I be billing based on the 95%tile of routes seen from the session, or the peak/min/max ? I would say the max, since that's the highest cost.

As a buyer of internet services, you want a predictable cost (to some extent) so you can budget and manage it appropriately.

Adding another variable feels like "evil telco" charge you for whatever I can get away with mode. It also would take some time to have customers sign new contracts with such terms...

- Jared
Re: CloudFlare IPv6 BGP announcements - WTF guys? [ In reply to ]
On Jul 17, 2012, at 9:21 AM, Sascha Luck wrote:

> On Tue, Jul 17, 2012 at 08:53:24AM -0400, Jared Mauch wrote:
>
>> I think the issue here is people that feel entitled to pollute a global
>> network of routers, etc and impose their policy upon my network.
>
> I'm working on the assumption that some operators do this out of
> operational necessity, not stupidity or "because they can"
> Like all assumptions, it is probably flawed.

I suspect it may be. I've come to learn in my recent departure from backbone engineering that companies can't even enumerate their IP address assets. This is a foreign concept to me entirely, but its far too common. I've also observed that most people can't configure BGP properly and it results in a significant number of routing table leaks. These are things that could be easily solved, but the vendors are unwilling to make the necessary changes to improve the situation.

>> There are community driven models of this, through the RIR. Keeping
>> IPv6 table growth reasonably by complying with these policies isn't
>> that hard. I think that's the problem that myself and others see here.
>> If you feel entitled to announce a few /64's or /128's to your ISP and
>> they accept them, then great. That doesn't mean they are globally
>> reachable.
>
> I've no problem with using PIv6 or indeed separate /32 PAv6 for such purposes either, provided the RIR policies allow for such use. This may well be the best compromise.

Nor do I.

>> CloudFlare may have legitimate reasons for doing what they are here.
>
> I've seen more deaggregated announcements lately, often connected to some kind of business continuity / disaster recovery service. I don't like it either but it suggests there is a genuine need that
> policy doesn't recognize right now.

If you buy all your services from $carrierX and those announcements are there for business continuity then great. You should also announce the aggregate someplace, or have them do it.

>
>> lawn/routing table" but there are real costs of these entries in the
>> RIB + FIB. I would rather not see a model where you're billed based on
>> your pollution, but that was the Sean Doran model of "send me a check"
>> for use of my FIB entry. I can assign a cost to it, can you?
>
> I don't like that argument. IMO it plays into the hands of the ITU and
> certain large operators where "termination fees" "per-ASN-billing" and "pay to play" are certainly on the wish list. I can't see a solution either though. In the short term, allowing the
> use of PIv6 for this purpose might help keeping it under control.

Nor do I. But its possible to assign a cost. Since a device like Cisco7600/6500 can have 256k IPv6 entries by default, I can take the cost of that fully populated chassis and divide by 256k. Multiply by number of devices in network and you start to get that cost for a simple recovery number, let alone one you can manage and have profit from. Some devices are inexpensive, some those slots are very valuable. I am waiting to see a few scaling walls be hit in the IPv4 world. It's coming soon, when global routes + internals start to reach 512k I expect to see some carriers have trouble.

- Jared
Re: CloudFlare IPv6 BGP announcements - WTF guys? [ In reply to ]
On Tue, Jul 17, 2012 at 09:38:15AM -0400, Jared Mauch wrote:
>>
>> I've no problem with using PIv6 or indeed separate /32 PAv6 for such
>> purposes either, provided the RIR policies allow for such use. This
>> may well be the best compromise.
>
>Nor do I.

Ok, allow PIv6 for this purpose and keep strict-filtering PAv6 space
should be an acceptable compromise that would at least control the
number of such prefixes as the LIRs would have to document them.

>If you buy all your services from $carrierX and those announcements are
>there for business continuity then great. You should also announce the
>aggregate someplace, or have them do it.

Last one of those that floated past me was (ipv4) deaggregated /24s out
of a /22 PIv4 assignment. Announced in different geographical areas to
different upstreams.
PI space though, so presumably within bounds.

rgds,
Sascha Luck
Re: CloudFlare IPv6 BGP announcements - WTF guys? [ In reply to ]
On 17.07.2012 08:13, Bernhard Schmidt wrote:

> If 50% of the networks had filtered more-specifics from the beginning,
> we would not be in the situation where people announced
> smaller-than-allocated and got through with it. It would just be a known
> fact that these would not work (like >/24 in IPv4).
>
> I have the bad feeling it is too late now.

Aaaand here is the next one.

www.rtl.de has IPv6 address 2a03:d680::200

grh.sixxs.net> sh bgp ipv6 2a03:d680::/32 long
[...]
* 2a03:d680::/48 2001:15f8:1::1 0 25384 3292
3320 20504 i

RTL is one of the large private TV stations in Germany (also called
Unterschichtenfernsehen). Does anyone have good contacts there? I tried,
but domain-admin@rtl.nl does not fill me with much hope.

Bernhard
Re: CloudFlare IPv6 BGP announcements - WTF guys? [ In reply to ]
On 18/07/2012 22:19, Bernhard Schmidt wrote:
> On 17.07.2012 08:13, Bernhard Schmidt wrote:
>
>> If 50% of the networks had filtered more-specifics from the beginning,
>> we would not be in the situation where people announced
>> smaller-than-allocated and got through with it. It would just be a known
>> fact that these would not work (like >/24 in IPv4).
>>
>> I have the bad feeling it is too late now.
>
> Aaaand here is the next one.
>
> www.rtl.de has IPv6 address 2a03:d680::200
>
> grh.sixxs.net> sh bgp ipv6 2a03:d680::/32 long
> [...]
> * 2a03:d680::/48 2001:15f8:1::1 0 25384 3292
> 3320 20504 i

Hi,

I'm hoping that this case study on IPv6 /48 filtering using RIPE Atlas
sheds some more light on this situation:
https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering

For ~500 IPv6 enabled RIPE Atlas probes, we see in the order of 1% that
seem to be affected by strict IPv6 route filtering to the destinations
mentioned in this thread.
This is probably an order-of-magnitude-type of number.

best regards,
Emile Aben
RIPE NCC
Re: CloudFlare IPv6 BGP announcements - WTF guys? [ In reply to ]
On 26.07.2012 10:19, Emile Aben wrote:

Hello Emile,

>>> If 50% of the networks had filtered more-specifics from the beginning,
>>> we would not be in the situation where people announced
>>> smaller-than-allocated and got through with it. It would just be a known
>>> fact that these would not work (like >/24 in IPv4).
>>>
>>> I have the bad feeling it is too late now.
>>
>> Aaaand here is the next one.
>>
>> www.rtl.de has IPv6 address 2a03:d680::200
>>
>> grh.sixxs.net> sh bgp ipv6 2a03:d680::/32 long
>> [...]
>> * 2a03:d680::/48 2001:15f8:1::1 0 25384 3292
>> 3320 20504 i
>
> Hi,
>
> I'm hoping that this case study on IPv6 /48 filtering using RIPE Atlas
> sheds some more light on this situation:
> https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering
>
> For ~500 IPv6 enabled RIPE Atlas probes, we see in the order of 1% that
> seem to be affected by strict IPv6 route filtering to the destinations
> mentioned in this thread.
> This is probably an order-of-magnitude-type of number.

Thanks, that test is very interesting. However, I feel there is a
systematic error in it, because it is quite hard to believe that
/48-PA-without-covering-prefix has even better reachability than a
normal /32-PA announcement.

I believe these errors are caused by some other (temporary) routing
issues going on. There are still a few known bad eggs in the transit
market and your four test destinations have a widely different transit set.

Would it be possible to repeat this test with all prefixes for the tests
being originated by the same entitity (i.e. RIPE themselves)?

Thanks,
Bernhard
Re: CloudFlare IPv6 BGP announcements - WTF guys? [ In reply to ]
Hi,

(I'm substituting for Emile for the time...)

> Would it be possible to repeat this test with all prefixes for the tests
> being originated by the same entitity (i.e. RIPE themselves)?

It is entirely possible to repeat these tests; however we at the NCC are not
entirely at liberty to announce address space just like that :-) It's
probably more productive to cooperate with someone who already does this.

Cheers,
Robert

1 2  View All