Re: well-known Anycast prefixes

[Bill Woodcock]

I imagine that the “description” of each entry in the list should include a 
machine-readable field indicating the use. 

There was a question about the use-case... I’m sure a lot of people in the ops 
community have their own reasons related to routing and filtering and so forth, 
but there’s also a huge demand for this kind of information, aggregated and 
sanity-checked, to support academic research at the graduate level. And the 
better we support those kids with real-world data, the more practical an 
education they receive, and the more ready they are to jump in to jobs we offer 
them in industry when they graduate. Supporting kids and networking graduate 
programs like that is a big part of our work, that tends not to be visible on 
the operations side. 

Academics downloaded routing-archive snapshots from us nearly 300 million 
times, last year, for example. 

-Bill


> On Mar 21, 2019, at 09:52, Ross Tajvar  wrote:
> 
> Not all any-casted prefixes are DNS resolvers and not all DNS resolvers are 
> anycasted. It sounds like you would be better served by a list of well-known 
> DNS resolvers.
> 
>> On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway  wrote:
>> 
>> On 3/21/19 10:59 AM, Frank Habicht wrote:
>> > Hi James,
>> > 
>> > On 20/03/2019 21:05, James Shank wrote:
>> >> I'm not clear on the use cases, though.  What are the imagined use cases?
>> >>
>> >> It might make sense to solve 'a method to request hot potato routing'
>> >> as a separate problem.  (Along the lines of Damian's point.)
>> > 
>> > my personal reason/motivation is this:
>> > Years ago I noticed that my traffic to the "I" DNS root server was
>> > traversing 4 continents. That's from Tanzania, East Africa.
>> > Not having a local instance (back then), we naturally sent the traffic
>> > to an upstream. That upstream happens to be in that club of those who
>> > don't have transit providers (which probably doesn't really matter, but
>> > means a "global" network).
>> 
>> /snip
>> 
>> > Greetings,
>> > Frank
>> > 
>> 
>> I can think of another ...
>> 
>> We rate-limit DNS from unknown quantities for reasons that should be 
>> obvious. We white-list traffic from known trusted (anycast) ones to 
>> prevent a DDoS attack from throttling legitimate queries. This would be 
>> a useful way to help auto-generate those ACLs.

Re: well-known Anycast prefixes

[Bryan Holloway]

On 3/21/19 11:52 AM, Ross Tajvar wrote:
Not all any-casted prefixes are DNS resolvers and not all DNS resolvers 
are anycasted. It sounds like you would be better served by a list of 
well-known DNS resolvers.


True on both counts, and that's why I said "help".


On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway > wrote:



On 3/21/19 10:59 AM, Frank Habicht wrote:
 > Hi James,
 >
 > On 20/03/2019 21:05, James Shank wrote:
 >> I'm not clear on the use cases, though.  What are the imagined
use cases?
 >>
 >> It might make sense to solve 'a method to request hot potato
routing'
 >> as a separate problem.  (Along the lines of Damian's point.)
 >
 > my personal reason/motivation is this:
 > Years ago I noticed that my traffic to the "I" DNS root server was
 > traversing 4 continents. That's from Tanzania, East Africa.
 > Not having a local instance (back then), we naturally sent the
traffic
 > to an upstream. That upstream happens to be in that club of those who
 > don't have transit providers (which probably doesn't really
matter, but
 > means a "global" network).

/snip

 > Greetings,
 > Frank
 >

I can think of another ...

We rate-limit DNS from unknown quantities for reasons that should be
obvious. We white-list traffic from known trusted (anycast) ones to
prevent a DDoS attack from throttling legitimate queries. This would be
a useful way to help auto-generate those ACLs.

Re: well-known Anycast prefixes

[Ross Tajvar]

Not all any-casted prefixes are DNS resolvers and not all DNS resolvers are
anycasted. It sounds like you would be better served by a list of
well-known DNS resolvers.

On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway  wrote:

>
> On 3/21/19 10:59 AM, Frank Habicht wrote:
> > Hi James,
> >
> > On 20/03/2019 21:05, James Shank wrote:
> >> I'm not clear on the use cases, though.  What are the imagined use
> cases?
> >>
> >> It might make sense to solve 'a method to request hot potato routing'
> >> as a separate problem.  (Along the lines of Damian's point.)
> >
> > my personal reason/motivation is this:
> > Years ago I noticed that my traffic to the "I" DNS root server was
> > traversing 4 continents. That's from Tanzania, East Africa.
> > Not having a local instance (back then), we naturally sent the traffic
> > to an upstream. That upstream happens to be in that club of those who
> > don't have transit providers (which probably doesn't really matter, but
> > means a "global" network).
>
> /snip
>
> > Greetings,
> > Frank
> >
>
> I can think of another ...
>
> We rate-limit DNS from unknown quantities for reasons that should be
> obvious. We white-list traffic from known trusted (anycast) ones to
> prevent a DDoS attack from throttling legitimate queries. This would be
> a useful way to help auto-generate those ACLs.
>

Re: well-known Anycast prefixes

[Bryan Holloway]

On 3/21/19 10:59 AM, Frank Habicht wrote:

Hi James,

On 20/03/2019 21:05, James Shank wrote:

I'm not clear on the use cases, though.  What are the imagined use cases?

It might make sense to solve 'a method to request hot potato routing'
as a separate problem.  (Along the lines of Damian's point.)


my personal reason/motivation is this:
Years ago I noticed that my traffic to the "I" DNS root server was
traversing 4 continents. That's from Tanzania, East Africa.
Not having a local instance (back then), we naturally sent the traffic
to an upstream. That upstream happens to be in that club of those who
don't have transit providers (which probably doesn't really matter, but
means a "global" network).


/snip


Greetings,
Frank



I can think of another ...

We rate-limit DNS from unknown quantities for reasons that should be 
obvious. We white-list traffic from known trusted (anycast) ones to 
prevent a DDoS attack from throttling legitimate queries. This would be 
a useful way to help auto-generate those ACLs.

Re: well-known Anycast prefixes

[Job Snijders]

On Thu, Mar 21, 2019 at 06:59:18PM +0300, Frank Habicht wrote:
> On 20/03/2019 21:05, James Shank wrote:
> > I'm not clear on the use cases, though.  What are the imagined use cases?
> > 
> > It might make sense to solve 'a method to request hot potato routing'
> > as a separate problem.  (Along the lines of Damian's point.)
> 
> my personal reason/motivation is this:
> Years ago I noticed that my traffic to the "I" DNS root server was
> traversing 4 continents. That's from Tanzania, East Africa.
> Not having a local instance (back then), we naturally sent the traffic
> to an upstream. That upstream happens to be in that club of those who
> don't have transit providers (which probably doesn't really matter, but
> means a "global" network).

Luckily there are other root servers too! :)

> My Theory :
> So just because one I-root instance was hosted at a customer (or
> customer's customer), that got higher local-pref and now packets take
> the long way from Africa via Europe, NorthAmerica to Asia and that
> customer in Thailand. While closer I-root instances would obviously be
> along the way, just not from a paying customer, "only" from peering.
> 
> I don't know whether or not to blame that "carrier" for intentionally(?)
> carrying the traffic that far - presumably the $ they got for that from
> the I-root host in Thailand was worth it, and not enough customers
> complained enough about the latency?
> 
> But I think it would be worthwhile to give them an option and produce a
> mechanism of knowing what's anycasted.
> 
> Maybe (thinking of it) a solution for really well-known prefixes
> available at many instances/locations (like DNS root) would be to have
> their fixed set of direct transits at all the "global" nodes and
> everywhere else to tell peers to not advertise this to upstreams.

In all instances of what you mention you need cooperation from the
network which is routing in a (from your perspective) suboptimal way.

Either the customer of that upstream should use BGP communities to
localize the announcement, or the upstream themselves need to change
their routing policy to set 'same LOCAL_PREF everywhere' for some
prefixes. Of course any input channel into routing policy can be a
vector of abuse.

Even if you equalize the LOCAL_PREF attribute across your network edge,
you still have other tie breakers such as AS_PATH length. It is not
clear to me how a list of well-known anycast addresses, in practise,
would help swing the pendulum. In all cases you need cooperation from a
lot of networks, and the outcome is not clearly defined because we don't
have a true inter-domain 'shortest latency path' metric.

Kind regards,

Job

Re: well-known Anycast prefixes

[Frank Habicht]

Hi James,

On 20/03/2019 21:05, James Shank wrote:
> I'm not clear on the use cases, though.  What are the imagined use cases?
> 
> It might make sense to solve 'a method to request hot potato routing'
> as a separate problem.  (Along the lines of Damian's point.)

my personal reason/motivation is this:
Years ago I noticed that my traffic to the "I" DNS root server was
traversing 4 continents. That's from Tanzania, East Africa.
Not having a local instance (back then), we naturally sent the traffic
to an upstream. That upstream happens to be in that club of those who
don't have transit providers (which probably doesn't really matter, but
means a "global" network).

My Theory :
So just because one I-root instance was hosted at a customer (or
customer's customer), that got higher local-pref and now packets take
the long way from Africa via Europe, NorthAmerica to Asia and that
customer in Thailand. While closer I-root instances would obviously be
along the way, just not from a paying customer, "only" from peering.

I don't know whether or not to blame that "carrier" for intentionally(?)
carrying the traffic that far - presumably the $ they got for that from
the I-root host in Thailand was worth it, and not enough customers
complained enough about the latency?

But I think it would be worthwhile to give them an option and produce a
mechanism of knowing what's anycasted.

Maybe (thinking of it) a solution for really well-known prefixes
available at many instances/locations (like DNS root) would be to have
their fixed set of direct transits at all the "global" nodes and
everywhere else to tell peers to not advertise this to upstreams.

Greetings,
Frank

Re: well-known Anycast prefixes

[James Shank]

On 3/19/19 5:03 PM, Bill Woodcock wrote:
> 
> 
>> On Mar 19, 2019, at 1:55 PM, Frank Habicht  wrote:
>>
>> Hi,
>>
>> On 19/03/2019 23:13, Bill Woodcock wrote:
>>> Generally, static lists like that are difficult to maintain when
>>> they’re tracking multiple routes from multiple parties.
>>
>> agreed.
>> and on the other extreme, communities are very much prone to abuse.
>> I guess I could set any community on a number of prefixes (incl anycast)
>> right now
>>
>> So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted
>> {cymru[1], pch[2], ...}  could be good [3].
> 
> Ok, so, just trying to flesh out the idea to something that can be usefully 
> implemented…
> 
> 1) People send an eBGP multi-hop feed of well-known-community routes to a 
> collector, or send them over normal peering sessions to something that 
> aggregates…
> 
> 2) Because those are over BGP sessions, the counterparty is known, and can be 
> asked for details or clarification by the “moderator,” or the sender could 
> log in to an interface to add notes about the prefixes, as they would in the 
> IXPdir or PeeringDB.
> 
> 3) Known prefixes from known parties would be passed through in real-time, as 
> they were withdrawn and restored.
> 
> 4) New prefixes from known parties would be passed through in real-time if 
> they weren’t unusual (large/overlapping something else/previously announced 
> by other ASNs).
> 
> 5) New prefixes from known parties would be “moderated” if they were unusual.
> 
> 6) New prefixes from new parties would be “moderated” to establish that they 
> were legit and that there was some documentation explaining what they were.
> 
> 7) For anyone who really didn’t want to provide a community-tagged BGP feed, 
> a manual submission process would exist.
> 
> 8) Everything gets published as a real-time eBGP feed.
> 
> 9) Everything gets published as HTTPS-downloadable JSON.
> 
> 10) Everything gets published as a human-readable (and crawler-indexable) web 
> page.
> 
> Does that sound about right?
> 
> -Bill

Hi,

Interesting discussion and ideas.  I like how you've laid it out
above, Bill.

I'm not clear on the use cases, though.  What are the imagined use cases?

It might make sense to solve 'a method to request hot potato routing'
as a separate problem.  (Along the lines of Damian's point.)

Thanks!

James

-- 
James Shank
Senior Technical Advisor; Team Cymru, Inc.
jsh...@cymru.com; +1-847-378-3365; http://www.team-cymru.com/

Re: well-known Anycast prefixes

[Frank Habicht]

Hi,

On 20/03/2019 00:03, Bill Woodcock wrote:
> Ok, so, just trying to flesh out the idea to something that can be
> usefully implemented…
> 
> 1) People send an eBGP multi-hop feed of well-known-community routes
> to a collector, or send them over normal peering sessions to
> something that aggregates…

to clarify, eBGP multi-hop sounds good, that can be a dedicated session
for this purpose, BGP communities probably don't need to be added.
[for the case of 'normal peering sessions', it might seem "wasteful" to
use an additional IP on multiple peering LANs]

...


> Does that sound about right?

to me yes.

Frank

Re: well-known Anycast prefixes

[Bill Woodcock]

> On Mar 19, 2019, at 1:55 PM, Frank Habicht  wrote:
> 
> Hi,
> 
> On 19/03/2019 23:13, Bill Woodcock wrote:
>> Generally, static lists like that are difficult to maintain when
>> they’re tracking multiple routes from multiple parties.
> 
> agreed.
> and on the other extreme, communities are very much prone to abuse.
> I guess I could set any community on a number of prefixes (incl anycast)
> right now
> 
> So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted
> {cymru[1], pch[2], ...}  could be good [3].

Ok, so, just trying to flesh out the idea to something that can be usefully 
implemented…

1) People send an eBGP multi-hop feed of well-known-community routes to a 
collector, or send them over normal peering sessions to something that 
aggregates…

2) Because those are over BGP sessions, the counterparty is known, and can be 
asked for details or clarification by the “moderator,” or the sender could log 
in to an interface to add notes about the prefixes, as they would in the IXPdir 
or PeeringDB.

3) Known prefixes from known parties would be passed through in real-time, as 
they were withdrawn and restored.

4) New prefixes from known parties would be passed through in real-time if they 
weren’t unusual (large/overlapping something else/previously announced by other 
ASNs).

5) New prefixes from known parties would be “moderated” if they were unusual.

6) New prefixes from new parties would be “moderated” to establish that they 
were legit and that there was some documentation explaining what they were.

7) For anyone who really didn’t want to provide a community-tagged BGP feed, a 
manual submission process would exist.

8) Everything gets published as a real-time eBGP feed.

9) Everything gets published as HTTPS-downloadable JSON.

10) Everything gets published as a human-readable (and crawler-indexable) web 
page.

Does that sound about right?

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: well-known Anycast prefixes

[Frank Habicht]

Hi,

On 19/03/2019 23:13, Bill Woodcock wrote:
> Generally, static lists like that are difficult to maintain when
> they’re tracking multiple routes from multiple parties.

agreed.
and on the other extreme, communities are very much prone to abuse.
I guess I could set any community on a number of prefixes (incl anycast)
right now

So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted
{cymru[1], pch[2], ...}  could be good [3].

Frank Habicht
37084 / 33791
if that matters


{1] dealing with anycast?
[2] biased?
[3] speaking as someone not using (subscribing) any of the useful ones,
nor contributing to any...

Re: well-known Anycast prefixes

[Bill Woodcock]

> On Mar 19, 2019, at 1:11 PM, Grzegorz Janoszka  wrote:
> 
> On 2019-03-19 21:04, Hansen, Christoffer wrote:
>> https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.txt
>> PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly
>> format->style RPSL)
> 
> Most DNS root servers are anycasted.

Right, yeah, I think he was just showing an example, since he had roughly a 
dozen, out of thousands.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: well-known Anycast prefixes

[Bill Woodcock]

> On Mar 19, 2019, at 1:04 PM, Hansen, Christoffer  
> wrote:
> 
> something like this?
> 
> https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.txt
> 
> PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly
> format->style RPSL)

Generally, static lists like that are difficult to maintain when they’re 
tracking multiple routes from multiple parties.

Communities have been suggested, which works as long as they’re passed through 
to somewhere people can see.  Between PCH, RIS, and Route-Views, most should be 
visible somewhere, but not all.

I think a combination of the two is probably most useful…  people tag with a 
well-known community, then those get eBGP-multi-hopped to a common collector, 
and published as a clean machine-readable list.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: well-known Anycast prefixes

[Grzegorz Janoszka]

On 2019-03-19 21:04, Hansen, Christoffer wrote:

https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.txt
PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly
format->style RPSL)


Most DNS root servers are anycasted.

--
Grzegorz Janoszka

Re: well-known Anycast prefixes

[Hansen, Christoffer]

something like this?

https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.txt

PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly
format->style RPSL)

On 19/03/2019 18:12, Fredy Kuenzler wrote:
> I wonder whether anyone has ever compiled a list of well-known Anycast
> prefixes.
> 
> Such as
> 
> 1.1.1.0/24
> 8.8.8.0/24
> 9.9.9.0/24
> ...
> 
> Might be useful for a routing policy such as "always route hot-potato".
> 
> PS. this mail is not intended to start a flame war of hot vs. cold
> potato routing.
> 

-- 

Christoffer
0x18DD23C550293098DE07052A9DCF2CA008EBD2E8



signature.asc
Description: OpenPGP digital signature

Re: well-known Anycast prefixes

[Joe Provo]

On Tue, Mar 19, 2019 at 11:52:19AM -0700, Damian Menscher via NANOG wrote:
> Careful thought should be given into whether the BGP community means "this
> is an anycast prefix" vs "please hot-potato to this prefix".
> Latency-sensitive applications may prefer hot-potato to their network even
> if it's not technically an anycast range, as their private backbone may be
> faster (less congested) than the public internet.

To this point, it is pretty clear that any WK community covering this
will get [ab]used in a way that the prefix annoucer wishes. We'll then 
see operators only accepting the WKC if it matches their prefix lists
of known entities, getting us back to "hey maybe this should just be 
a registry I could reference".

Woody, maybe generate route-sets to publish in RPSL (RADB?), one per 
address-family, of observed anycasters?  It might be reasonable to do 
so in a format others can emulate if they wish to create/provide their 
own lists?

Cheers,

Joe

> Damian
> 
> On Tue, Mar 19, 2019 at 10:57 AM Siyuan Miao  wrote:
> 
> >
> > A Well-known BGP community will be better.
> >
> > You'll need to rewrite next hop or do something similar if AnyCast
> > prefixes are learnt from a multi hop BGP feed, and it made the
> > configuration more complicated and difficult to debug.
> >
> > On Wed, Mar 20, 2019, 01:48 Fredy Kuenzler  wrote:
> >
> >> Am 19.03.19 um 18:39 schrieb Bill Woodcock:
> >> >> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler 
> >> >> wrote: I wonder whether anyone has ever compiled a list of
> >> >> well-known Anycast prefixes.
> >> >
> >> > I don???t know of one.
> >> >
> >> > It seems like a good idea.
> >> >
> >> > BGP-multi-hop might be a reasonable way to collect them.
> >> >
> >> > If others agree that it???s a good idea, and it???s not stepping on
> >> > anyone???s toes, PCH would be happy to host/coordinate.
> >>
> >> Thanks for the effort, much appreciated.
> >>
> >> Am 19.03.19 um 18:40 schrieb Joe Provo:
> >> > I think one would want that internal and no rely upon someone else
> >> > maintaining it.  You might check if Oracle followed up on the
> >> > Renesys/Dyn work documented:
> >> > https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf
> >> >
> >> > ...where there were ~600 anycast v4 prefixes at the time.
> >>
> >> That's a lot %-]
> >>
> >> Maybe a well-known community (similar to RFC7999) could be defined and
> >> every Anycast operator could tag his prefixes? That's likely a better
> >> idea than manually maintain some list somewhere.
> >>
> >> --
> >> Fredy Kuenzler
> >>
> >> Init7 (Switzerland) Ltd.
> >> AS13030
> >> Technoparkstrasse 5
> >> CH-8406 Winterthur
> >> Skype:   flyingpotato
> >> Phone:   +41 44 315 4400
> >> Fax: +41 44 315 4401
> >> Twitter: @init7 / @kuenzler
> >> http://www.init7.net/
> >>
> >>

-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 

Re: well-known Anycast prefixes

[Damian Menscher via NANOG]

Careful thought should be given into whether the BGP community means "this
is an anycast prefix" vs "please hot-potato to this prefix".
Latency-sensitive applications may prefer hot-potato to their network even
if it's not technically an anycast range, as their private backbone may be
faster (less congested) than the public internet.

Damian

On Tue, Mar 19, 2019 at 10:57 AM Siyuan Miao  wrote:

>
> A Well-known BGP community will be better.
>
> You'll need to rewrite next hop or do something similar if AnyCast
> prefixes are learnt from a multi hop BGP feed, and it made the
> configuration more complicated and difficult to debug.
>
> On Wed, Mar 20, 2019, 01:48 Fredy Kuenzler  wrote:
>
>> Am 19.03.19 um 18:39 schrieb Bill Woodcock:
>> >> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler 
>> >> wrote: I wonder whether anyone has ever compiled a list of
>> >> well-known Anycast prefixes.
>> >
>> > I don’t know of one.
>> >
>> > It seems like a good idea.
>> >
>> > BGP-multi-hop might be a reasonable way to collect them.
>> >
>> > If others agree that it’s a good idea, and it’s not stepping on
>> > anyone’s toes, PCH would be happy to host/coordinate.
>>
>> Thanks for the effort, much appreciated.
>>
>> Am 19.03.19 um 18:40 schrieb Joe Provo:
>> > I think one would want that internal and no rely upon someone else
>> > maintaining it.  You might check if Oracle followed up on the
>> > Renesys/Dyn work documented:
>> > https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf
>> >
>> > ...where there were ~600 anycast v4 prefixes at the time.
>>
>> That's a lot %-]
>>
>> Maybe a well-known community (similar to RFC7999) could be defined and
>> every Anycast operator could tag his prefixes? That's likely a better
>> idea than manually maintain some list somewhere.
>>
>> --
>> Fredy Kuenzler
>>
>> Init7 (Switzerland) Ltd.
>> AS13030
>> Technoparkstrasse 5
>> CH-8406 Winterthur
>> Skype:   flyingpotato
>> Phone:   +41 44 315 4400
>> Fax: +41 44 315 4401
>> Twitter: @init7 / @kuenzler
>> http://www.init7.net/
>>
>>

Re: well-known Anycast prefixes

[Siyuan Miao]

A Well-known BGP community will be better.

You'll need to rewrite next hop or do something similar if AnyCast prefixes
are learnt from a multi hop BGP feed, and it made the configuration more
complicated and difficult to debug.

On Wed, Mar 20, 2019, 01:48 Fredy Kuenzler  wrote:

> Am 19.03.19 um 18:39 schrieb Bill Woodcock:
> >> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler 
> >> wrote: I wonder whether anyone has ever compiled a list of
> >> well-known Anycast prefixes.
> >
> > I don’t know of one.
> >
> > It seems like a good idea.
> >
> > BGP-multi-hop might be a reasonable way to collect them.
> >
> > If others agree that it’s a good idea, and it’s not stepping on
> > anyone’s toes, PCH would be happy to host/coordinate.
>
> Thanks for the effort, much appreciated.
>
> Am 19.03.19 um 18:40 schrieb Joe Provo:
> > I think one would want that internal and no rely upon someone else
> > maintaining it.  You might check if Oracle followed up on the
> > Renesys/Dyn work documented:
> > https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf
> >
> > ...where there were ~600 anycast v4 prefixes at the time.
>
> That's a lot %-]
>
> Maybe a well-known community (similar to RFC7999) could be defined and
> every Anycast operator could tag his prefixes? That's likely a better
> idea than manually maintain some list somewhere.
>
> --
> Fredy Kuenzler
>
> Init7 (Switzerland) Ltd.
> AS13030
> Technoparkstrasse 5
> CH-8406 Winterthur
> Skype:   flyingpotato
> Phone:   +41 44 315 4400
> Fax: +41 44 315 4401
> Twitter: @init7 / @kuenzler
> http://www.init7.net/
>
>

Re: well-known Anycast prefixes

[Fredy Kuenzler]

Am 19.03.19 um 18:39 schrieb Bill Woodcock:
>> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler  
>> wrote: I wonder whether anyone has ever compiled a list of 
>> well-known Anycast prefixes.
> 
> I don’t know of one.
> 
> It seems like a good idea.
> 
> BGP-multi-hop might be a reasonable way to collect them.
> 
> If others agree that it’s a good idea, and it’s not stepping on 
> anyone’s toes, PCH would be happy to host/coordinate.

Thanks for the effort, much appreciated.

Am 19.03.19 um 18:40 schrieb Joe Provo:
> I think one would want that internal and no rely upon someone else
> maintaining it.  You might check if Oracle followed up on the 
> Renesys/Dyn work documented: 
> https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf
> 
> ...where there were ~600 anycast v4 prefixes at the time.

That's a lot %-]

Maybe a well-known community (similar to RFC7999) could be defined and
every Anycast operator could tag his prefixes? That's likely a better
idea than manually maintain some list somewhere.

-- 
Fredy Kuenzler

Init7 (Switzerland) Ltd.
AS13030
Technoparkstrasse 5
CH-8406 Winterthur
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax: +41 44 315 4401
Twitter: @init7 / @kuenzler
http://www.init7.net/



signature.asc
Description: OpenPGP digital signature

RE: well-known Anycast prefixes

[David Guo via NANOG]

Hi Fredy,

Our anycast prefixes for DNS resolver

185.222.222.0/24
2a09::/48

You can add them if someone will maintain a list.

Regards,

David

-Original Message-
From: NANOG  On Behalf Of Fredy Kuenzler
Sent: Wednesday, March 20, 2019 1:13 AM
To: nanog@nanog.org
Subject: well-known Anycast prefixes

I wonder whether anyone has ever compiled a list of well-known Anycast prefixes.

Such as

1.1.1.0/24
8.8.8.0/24
9.9.9.0/24
...

Might be useful for a routing policy such as "always route hot-potato".

PS. this mail is not intended to start a flame war of hot vs. cold potato 
routing.

--
Fredy Kuenzler

Init7 (Switzerland) Ltd.
AS13030
Technoparkstrasse 5
CH-8406 Winterthur
Twitter: @init7 / @kuenzler
http://www.init7.net/

Re: well-known Anycast prefixes

[Bill Woodcock]

> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler  wrote:
> 
> I wonder whether anyone has ever compiled a list of well-known Anycast
> prefixes.

I don’t know of one.

It seems like a good idea.

BGP-multi-hop might be a reasonable way to collect them.

If others agree that it’s a good idea, and it’s not stepping on anyone’s toes, 
PCH would be happy to host/coordinate.

-Bill



signature.asc
Description: Message signed with OpenPGP