Mailing List Archive: nsp: ipv6

CloudFlare IPv6 BGP announcements - WTF guys?

1 2

View All

Index | Next | Previous | View Threaded

olipro at 8

Jul 14, 2012, 4:34 AM

Post #1 of 32 (1493 views)
Permalink

CloudFlare IPv6 BGP announcements - WTF guys?

So, doing a "sh bgp ipv6 uni 2400:cb00::/32 long" reveals that CloudFlare are
currently announcing a bunch of /48s to the rest of the internet through
nLayer only - as far as I can see.

Simple suggestion: announce the /32 to the internet from all peering points
like good Netizens and then announce your /48s from whatever peering it is you
want the traffic sent to and tag it with the NO_EXPORT community attribute so
you're not spamming up everyone's tables or hoisting yourselves by your own
petard by getting filtered out.

Kind Regards,
Oliver

randy at psg

Jul 14, 2012, 5:22 AM

Post #2 of 32 (1435 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

> So, doing a "sh bgp ipv6 uni 2400:cb00::/32 long" reveals that
> CloudFlare are currently announcing a bunch of /48s to the rest
> of the internet through nLayer only - as far as I can see.

gossip is cloudflare has most, of not all, eggs in one basket,
but a pollute commons routing policy. sad to say, this is not
uncommon, just unwise. check for it when they put out the s1.

randy

berni at birkenwald

Jul 14, 2012, 1:45 PM

Post #3 of 32 (1435 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On 14.07.2012 13:34, Oliver wrote:
> So, doing a "sh bgp ipv6 uni 2400:cb00::/32 long" reveals that CloudFlare are
> currently announcing a bunch of /48s to the rest of the internet through
> nLayer only - as far as I can see.
>
> Simple suggestion: announce the /32 to the internet from all peering points
> like good Netizens and then announce your /48s from whatever peering it is you
> want the traffic sent to and tag it with the NO_EXPORT community attribute so
> you're not spamming up everyone's tables or hoisting yourselves by your own
> petard by getting filtered out.

Akamai is (at least in RIPE space) now having the same problem. They
used to announce the /32 from somewhere and additional /48s, so at least
the traffic went somewhere. They dropped the /32 now, so everyone
filtering strict has no route to Akamai anymore.

FWIW, I'm talking about 2a02:26f0::/32. There are Akamai clusters in ISP
PA space that still work of course.

Bernhard

olipro at 8

Jul 16, 2012, 6:45 AM

Post #4 of 32 (1420 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Saturday 14 July 2012 22:45:34 Bernhard Schmidt wrote:
> Akamai is (at least in RIPE space) now having the same problem. They
> used to announce the /32 from somewhere and additional /48s, so at least
> the traffic went somewhere. They dropped the /32 now, so everyone
> filtering strict has no route to Akamai anymore.
>
> FWIW, I'm talking about 2a02:26f0::/32. There are Akamai clusters in ISP
> PA space that still work of course.
>
> Bernhard

The whole thing is daft; even if you've got multiple upstreams, there's still
*nothing* preventing you from exposing only your /32 to the rest of the
internet and tagging more specifics with NO_EXPORT to each of your upstreams.

The only time that doesn't solve the issue is when you specifically want to
force a given prefix to a particular point through a particular upstream;
although in that case, go create a route object or arrange something with your
transit providers.

If your modus operandi is to pollute the routing tables, you deserve all the
unreachability you get.

Regards,
Oliver

dr at cluenet

Jul 16, 2012, 12:15 PM

Post #5 of 32 (1414 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Mon, Jul 16, 2012 at 03:45:43PM +0200, Oliver wrote:
> The whole thing is daft; even if you've got multiple upstreams, there's still
> *nothing* preventing you from exposing only your /32 to the rest of the
> internet and tagging more specifics with NO_EXPORT to each of your upstreams.

Not having a backbone pretty effectively does.

> If your modus operandi is to pollute the routing tables, you deserve all the
> unreachability you get.

Wether you see /32 PA more-specifics from all the CDN nodes, or PI /48s
doesn't make a difference at all, technically.

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0

olipro at 8

Jul 16, 2012, 12:49 PM

Post #6 of 32 (1415 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Monday 16 July 2012 21:15:17 Daniel Roesen wrote:
> On Mon, Jul 16, 2012 at 03:45:43PM +0200, Oliver wrote:
> > The whole thing is daft; even if you've got multiple upstreams, there's
> > still *nothing* preventing you from exposing only your /32 to the rest of
> > the internet and tagging more specifics with NO_EXPORT to each of your
> > upstreams.
>
> Not having a backbone pretty effectively does.

...Which would fall under the second paragraph of my previous e-mail regarding
the need for a particular subnet's traffic to go via a particular upstream.

>
> > If your modus operandi is to pollute the routing tables, you deserve all
> > the unreachability you get.
>
> Wether you see /32 PA more-specifics from all the CDN nodes, or PI /48s
> doesn't make a difference at all, technically.

I'd have hoped this was self-evident and serves to highlight the fact that the
protection against such abuse is down to RIR policies governing eligibility
for PI space.

Regards,
Oliver

v6ops at stefan-neufeind

Jul 16, 2012, 1:18 PM

Post #7 of 32 (1421 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On 07/16/2012 09:49 PM, Oliver wrote:
> On Monday 16 July 2012 21:15:17 Daniel Roesen wrote:
>> On Mon, Jul 16, 2012 at 03:45:43PM +0200, Oliver wrote:
>>> The whole thing is daft; even if you've got multiple upstreams, there's
>>> still *nothing* preventing you from exposing only your /32 to the rest of
>>> the internet and tagging more specifics with NO_EXPORT to each of your
>>> upstreams.
>>
>> Not having a backbone pretty effectively does.
>
> ...Which would fall under the second paragraph of my previous e-mail regarding
> the need for a particular subnet's traffic to go via a particular upstream.
>
>>
>>> If your modus operandi is to pollute the routing tables, you deserve all
>>> the unreachability you get.
>>
>> Wether you see /32 PA more-specifics from all the CDN nodes, or PI /48s
>> doesn't make a difference at all, technically.
>
> I'd have hoped this was self-evident and serves to highlight the fact that the
> protection against such abuse is down to RIR policies governing eligibility
> for PI space.

But I agree with Daniel it wouldn't actually make much of a difference
(technically). Well, for the RIRs it's of course many more shiny new
ressources in their statistics, more work and more money. I don't
believe getting individual /48-allocations is any better than "clean"
subnets.

Regards,
Stefan

berni at birkenwald

Jul 16, 2012, 1:27 PM

Post #8 of 32 (1412 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On 16.07.2012 21:15, Daniel Roesen wrote:

>> If your modus operandi is to pollute the routing tables, you deserve all the
>> unreachability you get.
> Wether you see /32 PA more-specifics from all the CDN nodes, or PI /48s
> doesn't make a difference at all, technically.

It does in a way. With multiple allocated prefixes (be it /32 or /48, I
don't care) you can be reasonably certain it has been "designed" this
way for your non-interconnected sites. With dozens
less-than-allocation-size prefixes there is no way to programatically
seperate you from the next hillbilly-ISP that never heard of communities
or proper aggregation and just announces their whole iBGP into the world.

Sure, you can put exceptions for Akamai and Cloudflare in your filters.
And then the next CDN-of-the-day, and then ...

I have absolutely nothing against proper and reasonable use of BGP, be
it more-specific or otherwise, but I don't want the next iBGP leak
hitting my routers. So I was filtering on /36 for PA space until now,
hoping for a consensus in the community. Since Akamai still does not
have that /32 in the air again I have to assume it is intentional and
the battle for strict filtering is essentially lost.

Bernhard

lists at c4inet

Jul 16, 2012, 1:30 PM

Post #9 of 32 (1411 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Mon, Jul 16, 2012 at 09:49:27PM +0200, Oliver wrote:

>> Wether you see /32 PA more-specifics from all the CDN
>> nodes, or PI /48s doesn't make a difference at all,
>> technically.

>I'd have hoped this was self-evident and serves to
>highlight the fact that the protection against such
>abuse is down to RIR policies governing eligibility
>for PI space.

how *exactly* does making it harder or impossible to get PI space
protect (whom?) against deaggregation of PA /32s?

>Regards,
>Oliver

rgds,
Sascha Luck

olipro at 8

Jul 16, 2012, 1:47 PM

Post #10 of 32 (1404 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Monday 16 July 2012 21:30:10 Sascha Luck wrote:
> how *exactly* does making it harder or impossible to get PI space
> protect (whom?) against deaggregation of PA /32s?

As it stands, the /48s announced by CloudFlare from their /32 *are* getting
filtered by (some) ASs.

I'll leave it as an exercise to the reader to ascertain the how and why.

Regards,
Oliver

brandon at bogons

Jul 16, 2012, 1:56 PM

Post #11 of 32 (1408 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Mon Jul 16, 2012 at 09:15:17PM +0200, Daniel Roesen wrote:
> Wether you see /32 PA more-specifics from all the CDN nodes, or PI /48s
> doesn't make a difference at all, technically.

It makes a huge differnce.

With the latter the /48's will be from a range we expect /48's
from (hopefully). With the former it's from a range we'd rather
not have to leave open to /48's. Slightly classful can be useful.

For their use it is no difference but from my view it is a huge
risk - potentially anyone can easily have accepted a more specific
for me or something important to me. I'd rather we all didn't have
to accept that, thus people are more likely to have reasonable
deagg filters. Some will just deagg crazily too given the chance
made possible by people like CloudFlare.

Keep a sensible deagg filter and CloudFlare may fix themselves
and not put anyone else at more risk.

brandon

lists at c4inet

Jul 16, 2012, 1:58 PM

Post #12 of 32 (1404 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Mon, Jul 16, 2012 at 10:47:16PM +0200, Oliver wrote:

>As it stands, the /48s announced by CloudFlare from
>their /32 *are* getting filtered by (some) ASs.
>
>I'll leave it as an exercise to the reader to
>ascertain the how and why.

Oh, your argument is that PI space should be used for
this sort of traffic engineering?
I agree and I'd go further and say that the traditional
PA/PI distinction serves no useful purpose anymore as
there are now a number of use-cases where neither fits the
requirements very well.
I don't see that going away in my lifetime though and, as
Daniel says, it wouldn't make a huge difference to the
overall ipv6 DFZ size.

rgds,
Sascha Luck

brandon at bogons

Jul 16, 2012, 2:00 PM

Post #13 of 32 (1407 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Mon Jul 16, 2012 at 09:30:10PM +0100, Sascha Luck wrote:
> how *exactly* does making it harder or impossible to get PI space
> protect (whom?) against deaggregation of PA /32s?

I'd rather a few bogus PIs than rampant deagg risk or actual.

brandon

olipro at 8

Jul 16, 2012, 2:14 PM

Post #14 of 32 (1418 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Monday 16 July 2012 21:58:37 Sascha Luck wrote:
> Oh, your argument is that PI space should be used for
> this sort of traffic engineering?
> I agree and I'd go further and say that the traditional
> PA/PI distinction serves no useful purpose anymore as
> there are now a number of use-cases where neither fits the
> requirements very well.
> I don't see that going away in my lifetime though and, as
> Daniel says, it wouldn't make a huge difference to the
> overall ipv6 DFZ size.

Absolutely not, on the contrary, my argument is that doing such a thing would
be a misuse of PI space.

The solution is to announce what you're given without deaggregating - that's
not my opinion so much as a fact of life given that AS operators can and do
perform strict filtering of the IPv6 DFZ.

Regards,
Oliver

lists at c4inet

Jul 16, 2012, 2:36 PM

Post #15 of 32 (1406 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Mon, Jul 16, 2012 at 11:14:07PM +0200, Oliver wrote:
>Absolutely not, on the contrary, my argument is that
>doing such a thing would be a misuse of PI space.
>
>The solution is to announce what you're given
>without deaggregating -

So rules and regulations should supercede operational
necessities, such as they may be?
The Internet has changed since 1995 and the system
devised by the wise old men does just not fit the
current usage anymore.

If allocation/assignment policies do not fit the current
use cases anymore, *policies* will have to change rather
than forcing operators into a model designed by a few
people in the 1990s.
This may or may not also involve the design of a routing
protocol that can handle this new paradigm.

>that's not my opinion so much as a fact of life given
>that AS operators can and do perform strict filtering
>of the IPv6 DFZ.

Which, IMO does a lot more harm to ipv6 adoption than
a few deagreggated /48s in a routing table that is by
no means crowded (yet) anyway.

inet6.0: 9587/9587/9587/0

meh, excuse me for not panicking just yet...

rgds,

Sascha Luck

berni at birkenwald

Jul 16, 2012, 2:44 PM

Post #16 of 32 (1404 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On 16.07.2012 23:36, Sascha Luck wrote:

> Which, IMO does a lot more harm to ipv6 adoption than
> a few deagreggated /48s in a routing table that is by no means crowded
> (yet) anyway.
>
> inet6.0: 9587/9587/9587/0
>
> meh, excuse me for not panicking just yet...

You will never be able to make it strict later, there will always be
networks on auto-pilot saying "this used to work, I don't care". Which
is why I was advocating for strict filtering in the beginning.

Bernhard

lists at c4inet

Jul 16, 2012, 3:16 PM

Post #17 of 32 (1411 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Mon, Jul 16, 2012 at 11:44:26PM +0200, Bernhard Schmidt wrote:
>You will never be able to make it strict later, there will always be
>networks on auto-pilot saying "this used to work, I don't care".
>Which is why I was advocating for strict filtering in the beginning.

Granted. The reaction of the customers - who know nothing about
DFZs and RIR politics - of both the filtering and the filtered
operators, will be something along the lines of:
"Bugger this IPv6 lark, it's useless,I can't reach a thing"
And I figure uptake is fragile enough to not hamper it any more than
absolutely necessary.

rgds,
Sascha Luck

olipro at 8

Jul 16, 2012, 4:34 PM

Post #18 of 32 (1406 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Monday 16 July 2012 23:16:03 Sascha Luck wrote:
> Granted. The reaction of the customers - who know nothing about
> DFZs and RIR politics - of both the filtering and the filtered
> operators, will be something along the lines of:
> "Bugger this IPv6 lark, it's useless,I can't reach a thing"
> And I figure uptake is fragile enough to not hamper it any more than
> absolutely necessary.

Given the widespread implementation of Happy Eyeballs, not really.

Even without it, Joe Q. Public is unlikely to even *know* it's anything to do
with v6 - businesses who need CDN will vote with their feet and avoid
companies who use their address space in such a way that global reachability
isn't ensured.

At this point you come across as little more than a shill for the CDNs wanting
to avoid implementing proper infrastructure and sensible routing policy.

Regards,
Oliver

lists at c4inet

Jul 16, 2012, 5:26 PM

Post #19 of 32 (1402 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Tue, Jul 17, 2012 at 01:34:39AM +0200, Oliver wrote:

>At this point you come across as little more than a
shill for the CDNs wanting >to avoid implementing
proper infrastructure and sensible routing policy.

-1, Troll.

I don't work or speak for any CDN.I don't even announce
any de-aggregated prefixes on either ipv4 or ipv6.
However I run real networks with real customers for a
living and *I* know that the important thing is to keep
the packets moving rather than pontificating, from a
great height, on the evils of "DFZ pollution".

Sincerely,

Sascha Luck

dr at cluenet

Jul 16, 2012, 6:57 PM

Post #20 of 32 (1412 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Mon, Jul 16, 2012 at 09:56:00PM +0100, Brandon Butterworth wrote:
> On Mon Jul 16, 2012 at 09:15:17PM +0200, Daniel Roesen wrote:
> > Wether you see /32 PA more-specifics from all the CDN nodes, or PI /48s
> > doesn't make a difference at all, technically.
>
> It makes a huge differnce.
>
> With the latter the /48's will be from a range we expect /48's
> from (hopefully). With the former it's from a range we'd rather
> not have to leave open to /48's. Slightly classful can be useful.

But that's not a technical difference (impacting FIB scaling), but an
operational difference (to which I fully agree).

OF COURSE the "right thing" would been to use a separate PI block per
CDN site.

I fail to see a technical reason not to do that, but I see multiple
economical and practical reasons.

On one hand, get a /32 for a one-time effort of becoming LIR and a
yearly (for Akamai etc.) low fee in the low 4-digit range and number
up to 2^16 CDN nodes from that without ever having to discuss with
the RIR. Oh, you can actually design some hierarchy into that /32 as
well.

The alternative: go to the RIR for every fscking new CDN node, submit
requests, wait for approvals, perhaps having to discuss nonsense with
newbie-IPRA-de-jure (time is money!), and pay 50 EUR [in RIPE case]
per anno per CDN node. Ah, and have all that tunnelled thru a LIR of
least mistrust which probably will also want to get paid for that
service. :)

Pretty convincing arguments to just shoot for getting and deagging
the /32, eh? Wait until the beancounters understand that concept. :)

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0

berni at birkenwald

Jul 16, 2012, 11:13 PM

Post #21 of 32 (1410 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

Am 17.07.2012 00:16, schrieb Sascha Luck:
> On Mon, Jul 16, 2012 at 11:44:26PM +0200, Bernhard Schmidt wrote:
>> You will never be able to make it strict later, there will always be
>> networks on auto-pilot saying "this used to work, I don't care". Which
>> is why I was advocating for strict filtering in the beginning.
>
> Granted. The reaction of the customers - who know nothing about DFZs and
> RIR politics - of both the filtering and the filtered operators, will
> be something along the lines of: "Bugger this IPv6 lark, it's useless,I
> can't reach a thing"
> And I figure uptake is fragile enough to not hamper it any more than
> absolutely necessary.

This is a similar argument to the reasons why no content offers wanted
to do IPv6 in the past. If you are the only one filtering/having AAAA
you are by definition the bad guy breaking the internet. If most are
filtering/having AAAA the blame is shifted to the people actually not
doing it correctly.

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.

Bernhard

gert at space

Jul 17, 2012, 1:04 AM

Post #22 of 32 (1416 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

Hi,

On Mon, Jul 16, 2012 at 10:36:35PM +0100, Sascha Luck wrote:
> Which, IMO does a lot more harm to ipv6 adoption than
> a few deagreggated /48s in a routing table that is by
> no means crowded (yet) anyway.

Uh, while the IPv6 routing table is not crouded, the amount of ("few")
deaggregated prefixes is actually somewhat unsettling - we see about
the same amount of prefixes announced "as allocated" and "more specific" -
about 4100 prefixes matching LIR allocations, and about 4000 being
"more specifics from LIR allocations", plus about 1200 "PI as assigned"
and 700 "more specific than assigned" (which might be due to aggregation
*in the assignment records* - like, 8 /48s given out, but documented as
a /45).

Further, the ratio between "exact match" and "more specific" has shifted
significantly in the last 18 months, from about 2:1 to about 1:1 now.

Numbers are here: http://www.space.net/~gert/RIPE/weekly/2012/29/ - pretty
far down the page, "Routing Table by Class of Prefix".

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

jared at puck

Jul 17, 2012, 5:53 AM

Post #23 of 32 (1384 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

On Jul 16, 2012, at 5:36 PM, Sascha Luck wrote:

> So rules and regulations should supercede operational
> necessities, such as they may be?
> The Internet has changed since 1995 and the system devised by the wise old men does just not fit the current usage anymore.
> If allocation/assignment policies do not fit the current use cases anymore, *policies* will have to change rather than forcing operators into a model designed by a few
> people in the 1990s. This may or may not also involve the design of a routing
> protocol that can handle this new paradigm.
>
>> that's not my opinion so much as a fact of life given
>> that AS operators can and do perform strict filtering of the IPv6 DFZ.
>
> Which, IMO does a lot more harm to ipv6 adoption than
> a few deagreggated /48s in a routing table that is by no means crowded (yet) anyway.
>
> inet6.0: 9587/9587/9587/0
>
> meh, excuse me for not panicking just yet...

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.

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.

CloudFlare may have legitimate reasons for doing what they are here. It could also be that getting a large block was easy and they figured they could deagg and not ask for a few more blocks per site. They could be in the process of building a network backbone and not have the ability to connect these sites together. They could have regional geopolitical reasons for segmenting this traffic.

I think the challenge here is that most people expect their prefix to be visible in the global DFZ. Those spaces cost money. While you're showing the output from some sort of juniper device, some platforms use TCAM that has to be partitioned at boot-time. Even if there is 'space', it may not be carved properly and the variance in growth in the v4 vs v6 speeds combined with the fact that customers have an unrealistic expectation that there will be no reboots of their devices means: You can't fix the problem until its an emergency in another 2-3 years.

While its just "one slot" here and there, holding the line on this is an important alignment between RIR allocation policies and the global backbone operators that didn't exist in the past. This may change, but right now those deploying IPv6 tend to be seasoned enough in the cost and risks involved here. You may think we're all saying "get 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, 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?

- Jared

p.mayers at imperial

Jul 17, 2012, 6:09 AM

Post #24 of 32 (1362 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

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?

lists at c4inet

Jul 17, 2012, 6:21 AM

Post #25 of 32 (1368 views)
Permalink

Re: CloudFlare IPv6 BGP announcements - WTF guys? [In reply to]

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.

>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.

>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.

>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.

rgds,
Sascha Luck

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads