Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

CloudFlare IPv6 BGP announcements - WTF guys?

 

 

First page Previous page 1 2 Next page Last page  View All nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


jared at puck

Jul 17, 2012, 6:32 AM

Post #26 of 32 (787 views)
Permalink
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


jared at puck

Jul 17, 2012, 6:38 AM

Post #27 of 32 (789 views)
Permalink
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


lists at c4inet

Jul 17, 2012, 8:41 AM

Post #28 of 32 (786 views)
Permalink
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


berni at birkenwald

Jul 18, 2012, 1:19 PM

Post #29 of 32 (779 views)
Permalink
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 [at] rtl does not fill me with much hope.

Bernhard


emile.aben at ripe

Jul 26, 2012, 1:19 AM

Post #30 of 32 (749 views)
Permalink
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


berni at birkenwald

Jul 29, 2012, 6:26 AM

Post #31 of 32 (732 views)
Permalink
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


robert at ripe

Jul 30, 2012, 2:20 AM

Post #32 of 32 (723 views)
Permalink
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

First page Previous page 1 2 Next page Last page  View All nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.