Re: netflix proxy/unblocker false detection

[Grant Taylor via NANOG]

On 6/26/20 1:42 PM, Sabri Berisha wrote:

Hi,


Hi,


This is the part that matters the most. I'm sure they're willing.


Let's agree to disagree on Netflix's willingness.

I'm also sure that in the past, enough people have abused their 
trust.


I question the veracity of that statement.

Since they are legally obliged to adhere to their licensing agreements, 
they have no choice but to implement technical precautions to enforce 
those agreements ...


I agree to that part of your statement.  What's more is I have no 
objection to it.  I even support it.



... to the best of their abilities.


This is where I have a problem.

I highly doubt the agreements that Netflix's has with content owners 
state that Hurricane Electric (et al.) must be blocked.  Maybe I'm 
wrong.  It wouldn't be the first time today.


I believe that Netflix is choosing the lower / easier road and simply 
blocking Hurricane Electric's IPv6 tunnels as an easy / low hanging 
fruit option to achieve the contractual requirements.


I do not believe that we are seeing the best of Netflix's abilities to 
filter content.  To be more blunt, I believe that Netflix is capable and 
can do better than they are doing now.


Amazon does better.
YouTube does better.
CBS does better.
Hulu does better.

Where better is working with my Hurricane Electric IPv6 tunnel and not 
forcing me to DNS filtering of  records for their domains, 
independent DNSSEC.


I can only speculate that Netflix doesn't care.  As such, they /choose/ 
this road through inaction on their part.



False positives (meaning, people being denied while being in-region), are going
to be an unwelcome side-effect.


This side effect is like forgetting about your hurt knee after hitting 
your thumb with a hammer, on purpose.



In the end, I must agree with Mike Hammett when he said:

Media licensing is a complicated topic and the source of all of these problems.


Without seeing actual licenses to support "you must block Hurricane 
Electric", I'm going to choose to disagree with the license scapegoat.


I believe that Netflix is capable of doing better if they wanted to.  I 
can only surmise that they don't want to.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: netflix proxy/unblocker false detection

[Grant Taylor via NANOG]

On 6/26/20 3:21 PM, William Herrin wrote:

Hi Grant,


Hi,


Philosophically, Netflix agrees with you.


My interactions with and observations of Netflix make me want to 
disagree with you.


Unfortunately they have to keep the studios happy or many of their 
content contracts evaporate.


I fail to see how me watching a video at my address on file, which 
matches my CC's address on file, which matches the GeoIP region for my 
IPv4 address becomes invalidated because I'm using IPv6.


There is nothing to stop Netflix from probing a mixture of IPv4 and IPv6 
during the same video playing session.  Thus they could correlate the 
IPv6 with the IPv4 which correlates with my CC which correlates with my 
address on file.


I firmly believe that Netflix /could/ solve IPv6 playback, even through 
VPN, if they wanted to.  I completely believe that Netflix is capable of 
solving this.  I also completely believe that Netflix doesn't give a 
REDACTED and chooses to ignore this problem.


Instead, they choose to foist the problem onto other parties.  Or pass 
the blame.



And too many content owners care very much where you are right this
instant.


Nope.  I disagree.

I can just as easily extend my IPv4 address through a VPN as I can an 
IPv6 address.  --  Performance may suffer, but that's a different issue.


I can use my home's IPv4 address, which is GeoIP located to the same 
area as my home which matches my CC billing address, can be used 
anywhere in the world.


So ... if I can use my IPv4 address outside of where Netflix thinks that 
I am at, why is my IPv6 address any different?


I completely believe that there are technical solutions to this problem. 
 I also completely agree that Netflix is choosing to ignore them.


Because they are unreasonable luddites who think that geographic 
monopolies make good business sense.


As stated above, where the Luddites, or Netflix as their agent, thinks 
my IP is located is actually divorced from where I am really watching 
from.  Or at least can be.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: netflix proxy/unblocker false detection

[William Herrin]

On Fri, Jun 26, 2020 at 12:34 PM Grant Taylor via NANOG  wrote:
> I want to agree, but I can't.  Move up the stack.  I pay my bill with a
> CC which has my billing address.  I would even be willing to tell
> Netflix my home address directly.
>
> If they are willing to trust the CC information to take my money, then
> they should also be willing to trust the information for my service address.
>
> If I want to use my Hurricane Electric IPv6 tunnel, to watch content
> that matches my stated address which matches my CC billing address,
> which matches my IPv4 address (region), then why the REDACTED can't I do
> so over my HE IPv6 tunnel?

Hi Grant,

Philosophically, Netflix agrees with you. Unfortunately they have to
keep the studios happy or many of their content contracts evaporate.
And too many content owners care very much where you are right this
instant. Because they are unreasonable luddites who think that
geographic monopolies make good business sense.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: netflix proxy/unblocker false detection

[Sabri Berisha]

- On Jun 26, 2020, at 12:32 PM, nanog nanog@nanog.org wrote:

Hi,

> they should also be willing to trust the information for my service address.

This is the part that matters the most. I'm sure they're willing. I'm also
sure that in the past, enough people have abused their trust. Since they are
legally obliged to adhere to their licensing agreements, they have no choice
but to implement technical precautions to enforce those agreements to the
best of their abilities.

False positives (meaning, people being denied while being in-region), are going
to be an unwelcome side-effect.

In the end, I must agree with Mike Hammett when he said:

> Media licensing is a complicated topic and the source of all of these 
> problems.

Thanks,

Sabri

Re: netflix proxy/unblocker false detection

[Grant Taylor via NANOG]

On 6/26/20 12:08 PM, Brandon Jackson via NANOG wrote:
Correct they block HE.net's tunnel broker IP's because they practically 
are at least for the sense of geo restrictions "VPN" that can be used to 
get around said geo restriction.


I want to agree, but I can't.  Move up the stack.  I pay my bill with a 
CC which has my billing address.  I would even be willing to tell 
Netflix my home address directly.


If they are willing to trust the CC information to take my money, then 
they should also be willing to trust the information for my service address.


If I want to use my Hurricane Electric IPv6 tunnel, to watch content 
that matches my stated address which matches my CC billing address, 
which matches my IPv4 address (region), then why the REDACTED can't I do 
so over my HE IPv6 tunnel?


I would even be willing to go through a physical snail mail confirmation 
loop.  I'll even pay a nominal fee to do so.


I want to watch content available in my region while I'm at the 
associated address.  Why can't I?


I think that blindly blocking Hurricane Electric IPv6 tunnels "because 
they can be used as a VPN" is an old way of thinking and completely 
fails to take other parts of the stack into account.


Netflix's blocking of HE IPv6 tunnels is preventing many people in the 
U.S.A. that have a non-IPv6-ISP from being able to use IPv6.  I've even 
heard of people actively not using IPv6 because of Netflix.



As much as I hate it as I use said tunnel service it is understandable


I disagree.


I don't really blame Netflix for this,


I do.

I blame the content producer/owners and the industry as a whole for 
mandating such restrictive practices.


Are the content producers / owners mandating "Block Hurricane Electric 
IPv6 tunnels" or are they mandating "Block playback to people that are 
outside of the playback region"?


My opinion is that Netflix is taking the low road as an easy way out 
while trying to shift blame to someone else.


Using that as an argument against Netflix for bad labeling of IP blocks 
at least in terms of IPv6 is not fair.


I completely believe that Netflix could do a LOT better than they are 
doing now.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: netflix proxy/unblocker false detection

[Mike Hammett]

Media licensing is a complicated topic and the source of all of these problems. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "colin johnston"  
To: "Brian J. Murrell"  
Cc: nanog@nanog.org 
Sent: Friday, June 26, 2020 1:15:24 PM 
Subject: Re: netflix proxy/unblocker false detection 

> On Fri, 2020-06-26 at 12:45 -0500, Mike Hammett wrote: 
>> I believe they're only blocking the HE v6 prefixes used for the VPN 
>> service. 
> 

I don’t understand the rational to block specific ipv6 ranges, for example the 
UK ipv6 ranges and Africa ipv6 ranges are not blocked from testing done here 
with satellite comms and fibre backhaul uk comms 

Col 

Re: netflix proxy/unblocker false detection

[colin johnston]

> On Fri, 2020-06-26 at 12:45 -0500, Mike Hammett wrote:
>> I believe they're only blocking the HE v6 prefixes used for the VPN
>> service. 
> 

I don’t understand the rational to block specific ipv6 ranges, for example the 
UK ipv6 ranges and Africa ipv6 ranges are not blocked from testing done here 
with satellite comms and fibre backhaul uk comms

Col

Re: netflix proxy/unblocker false detection

[Brian J. Murrell]

On Fri, 2020-06-26 at 12:45 -0500, Mike Hammett wrote:
> I believe they're only blocking the HE v6 prefixes used for the VPN
> service. 

I don't use any VPN service of HE but I still get errors from Netflix
when my client chooses my HE tunnel prefix as it's source.

Or I guess I should say I was, the last time I tried and have since
rejected Netflix's IPv6 hosts when the source address is the HE tunnel,
so force clients to choose a different source address.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Re: netflix proxy/unblocker false detection

[Brandon Jackson via NANOG]

Correct they block HE.net's tunnel broker IP's because they practically are
at least for the sense of geo restrictions "VPN" that can be used to get
around said geo restriction.

As much as I hate it as I use said tunnel service it is understandable and
I don't really blame Netflix for this, I blame the content producer/owners
and the industry as a whole for mandating such restrictive practices.

Using that as an argument against Netflix for bad labeling of IP blocks at
least in terms of IPv6 is not fair.


On Fri, Jun 26, 2020, 13:47 Mike Hammett  wrote:

> I believe they're only blocking the HE v6 prefixes used for the VPN
> service.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Gary E. Miller" 
> *To: *nanog@nanog.org
> *Sent: *Friday, June 26, 2020 12:25:07 PM
> *Subject: *Re: netflix proxy/unblocker false detection
>
> Yo Mark!
>
> On Fri, 26 Jun 2020 10:21:47 +0200
> Mark Tinka  wrote:
>
> > If you don't use some kind of device to connect to Netflix, if you
> > have a reasonably modern TV that supports a native Netflix app as
> > well as IPv6, you'd be good to go.
>
> Nope.  Netflix blocks a lot of IPv6.  Their blocking of HE has been
> discussed here many times.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can't measure it, you can't improve it." - Lord Kelvin
>
>

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 27 Jun, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  814894
Prefixes after maximum aggregation (per Origin AS):  309638
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  397512
Total ASes present in the Internet Routing Table: 68362
Prefixes per ASN: 11.92
Origin-only ASes present in the Internet Routing Table:   58780
Origin ASes announcing only one prefix:   24483
Transit ASes present in the Internet Routing Table:9582
Transit-only ASes present in the Internet Routing Table:299
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  50
Max AS path prepend of ASN ( 22394)  38
Prefixes from unregistered ASNs in the Routing Table:   815
Number of instances of unregistered ASNs:   816
Number of 32-bit ASNs allocated by the RIRs:  32220
Number of 32-bit ASNs visible in the Routing Table:   26515
Prefixes from 32-bit ASNs in the Routing Table:  122091
Number of bogon 32-bit ASNs visible in the Routing Table:11
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:537
Number of addresses announced to Internet:   2842787584
Equivalent to 169 /8s, 113 /16s and 127 /24s
Percentage of available address space announced:   76.8
Percentage of allocated address space announced:   76.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  274787

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   214375
Total APNIC prefixes after maximum aggregation:   62558
APNIC Deaggregation factor:3.43
Prefixes being announced from the APNIC address blocks:  207909
Unique aggregates announced from the APNIC address blocks:86051
APNIC Region origin ASes present in the Internet Routing Table:   10626
APNIC Prefixes per ASN:   19.57
APNIC Region origin ASes announcing only one prefix:   2978
APNIC Region transit ASes present in the Internet Routing Table:   1585
Average APNIC Region AS path length visible:4.7
Max APNIC Region AS path length visible: 27
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5710
Number of APNIC addresses announced to Internet:  769923200
Equivalent to 45 /8s, 228 /16s and 24 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:238352
Total ARIN prefixes after maximum aggregation:   109528
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   235569
Unique aggregates announced from the ARIN address blocks:119747
ARIN Region origin ASes present in the Internet Routing Table:18526
ARIN Prefixes per ASN:12.72
ARIN 

Re: netflix proxy/unblocker false detection

[Mike Hammett]

I believe they're only blocking the HE v6 prefixes used for the VPN service. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Gary E. Miller"  
To: nanog@nanog.org 
Sent: Friday, June 26, 2020 12:25:07 PM 
Subject: Re: netflix proxy/unblocker false detection 

Yo Mark! 

On Fri, 26 Jun 2020 10:21:47 +0200 
Mark Tinka  wrote: 

> If you don't use some kind of device to connect to Netflix, if you 
> have a reasonably modern TV that supports a native Netflix app as 
> well as IPv6, you'd be good to go. 

Nope. Netflix blocks a lot of IPv6. Their blocking of HE has been 
discussed here many times. 

RGDS 
GARY 
--- 
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 
g...@rellim.com Tel:+1 541 382 8588 

Veritas liberabit vos. -- Quid est veritas? 
"If you can't measure it, you can't improve it." - Lord Kelvin 

Re: netflix proxy/unblocker false detection

[Sabri Berisha]

- On Jun 26, 2020, at 1:21 AM, Mark Tinka mark.ti...@seacom.com wrote:

Hi,

> Sadly, PlayStation still don't support IPv6. Hopefully, it comes with
> the PS5, 

Don't hold your breath.  It's most likely not related to the capabilities
of the hardware, or even the kernel running on the platform.

> although I see no reason why the PS4 and PS3 can't.

My guess is that there is no IPv6 support because the backend doesn't 
support it.  I've seen this at previous employers where the network was ready
for IPv6, but back-end applications were lagging.  And that might require
development on a lot of games as well.

Perhaps we should start a rumor: "IPv6 has a lower ping!".  We'll get
thousands of gamers protesting for v6 in front of Sony's HQ :)

Thanks,

Sabri

Re: netflix proxy/unblocker false detection

[Gary E. Miller]

Yo Mark!

On Fri, 26 Jun 2020 10:21:47 +0200
Mark Tinka  wrote:

> If you don't use some kind of device to connect to Netflix, if you
> have a reasonably modern TV that supports a native Netflix app as
> well as IPv6, you'd be good to go.

Nope.  Netflix blocks a lot of IPv6.  Their blocking of HE has been
discussed here many times.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgpROuFfpyBMs.pgp
Description: OpenPGP digital signature

Re: Ensuring RPKI ROAs match your routing intent

[Randy Bush]

> Perhaps BGP Alerter is a solution for you:
> https://github.com/nttgin/BGPalerter 

yes!  very happy user here.  i run it into the slack api.

randy

Re: netflix proxy/unblocker false detection

[Owen DeLong]

> On Jun 25, 2020, at 8:38 AM, Mark Tinka  wrote:
> 
> 
> 
> On 25/Jun/20 16:45, Christian wrote:
>> wow. blaming support for IPv6 rather than using cgnat is a huge
>> stretch of credibility
> 
> I have no idea what's going through Netflix's mind - it's all, as my
> American friend would say, conjecturbation on my part.
> 
> CG-NAT isn't new, and if Netflix are still not able to consider it a
> "fixed issue", there is probably a reason why that is.
> 
> Ultimately, reaching out to them and asking their position on the matter
> seems like a path to an answer.
> 
> Mark.

I can’t speak for Netflix, but the reality is that there’s really no good
way to “fix” CGNAT other than migrating to IPv6 and eliminating it.

CGNAT by its nature combines multiple subscribers behind a single address.

When you make subscribers indistinguishable to the content provider, then
any subscriber in the group committing abuse is likely to get all the
subscribers in the group cut off. There’s no good way around that.

Expecting content providers to maintain some sort of record of every
eyeball provider’s CGNAT port mapping policy in order to do more granular
filtering simply does not scale.

So I don’t know how (or even if) Netflix will answer, but were I in their
shoes, I’d probably answer as follows:

“IPv4 is a technology which has been extended well past its
ability to provide a good user experience. CGNAT, while it
allows providers to try and extend the lifetime of IPv4
ultimately provides an increasingly degraded user experience.
We fully support IPv6. Deploying IPv6 support is the best
path to providing an improved user experience on Netflix
vs. CGNAT and IPv4.”

Seriously, if you were Netflix, what would be the point of putting serious
investment into attempts to solve what will become an increasingly intractable
problem when you already have a clear solution that scales and requires
relatively easy and inherently necessary upgrades by the eyeball ISP that
you’ve already completed on your side?

Owen

Re: netflix proxy/unblocker false detection

[Owen DeLong]

I take his statement more as:

“If Netflix wasn’t doing IPv6, they’d be in more of a corner
to resolve CGNAT issues. Since they support IPv6, likely their
response to CGNAT issues is ``Press your provider to do IPv6,
it’s better.’’”

Likely, that is true. Support for IPv6 isn’t at fault here. Rather, the
reality that IPv6 is a relatively easy way to offer a much better user
experience than CGNAT is in play here.

Owen


> On Jun 25, 2020, at 7:45 AM, Christian  wrote:
> 
> wow. blaming support for IPv6 rather than using cgnat is a huge stretch of 
> credibility
> 
> On 25/06/2020 10:20, Mark Tinka wrote:
>> 
>> On 25/Jun/20 11:08, Denys Fedoryshchenko wrote:
>> 
>>> Did anybody noticed that Netflix just became useless due to tons of
>>> proxy/unblocker false detection on CGNAT ranges?
>>> Even my home network is dual stack, i am absolutely sure there is no
>>> proxy/vpn/whatsoever (but ipv4 part is over CGNAT) - and i got
>>> "proxy/unblocker" message on my personal TV.
>>> And many other ISP sysadmins told me that recently this is a massive
>>> problem, and netflix support is frankly inadequate and does not want
>>> to solve the problem.
>>> I will not be surprised that they will begin to actively lose users
>>> due to such a shameful silly screwed up algorithm.
>>> Who in sober mind blocks all legit users due probably one or two
>>> suspicious users behind same IP range?
>> This isn't a new problem - for years, services that track what a single
>> IP address does can deny access if something looks amiss.
>> 
>> Of course, CG-NAT is a reality, but perhaps Netflix find it will be
>> easier to lose some customers than building infrastructure and support
>> to work out what is valid CG-NAT vs. mischief.
>> 
>> Probably would have been an easier case if Netflix didn't support IPv6,
>> but alas...
>> 
>> Mark.
> 
> -- 
> Christian de Larrinaga
> --

Re: netflix proxy/unblocker false detection

[Brian J. Murrell]

On Thu, 2020-06-25 at 17:32 -0500, Mike Hammett wrote:
> IPv6? 

I realize this list is for network operators, but as a user, when your
ISP doesn't provide IPv6, this is not possible.  Even with
tunnelbrokers like HE as they are blocked at Netflix.  I have to put
rules in my firewall to force the clients in my network to use the non-
HE addresses.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Re: netflix proxy/unblocker false detection

[Mark Tinka]

On 26/Jun/20 03:12, Denys Fedoryshchenko wrote:

>  
>
> Honestly, this is very confusing suggestion from Netflix support (i
> have native ipv6!).
> Looking to
> https://www.reddit.com/r/ipv6/comments/evv7r8/ipv6_and_netflix/ there
> is definitely some issues for other users too.

This seems to suggest Netflix detect for an block IPv6 transported over
a 6-in-4 tunnel.

Is this what you have?

Can't say I've ever heard of this issue. Interesting...

Mark.

Re: netflix proxy/unblocker false detection

[Mark Tinka]

On 25/Jun/20 18:08, Brandon Jackson via NANOG wrote:

> Actually it's a good thing that Netflix does support IPv6 for this. As
> any device using Netflix via IPv6 from your ISP would likely correctly
> be protected as not a VPN or proxy.
>
> The problem is the ISPs that deploy CGNAT without also deploying IPv6
> is ridiculous. They are directly affected by the death of IPv4 yet
> will not deploy IPv6, to me that is unacceptable.
>
> Unfortunately as well you have devices such as Roku who still refuse
> to support IPv6 at all, so even if said ISP deployed IPv6 at least
> users using Roku would still be in the same boat.

If you don't use some kind of device to connect to Netflix, if you have
a reasonably modern TV that supports a native Netflix app as well as
IPv6, you'd be good to go.

Sadly, PlayStation still don't support IPv6. Hopefully, it comes with
the PS5, although I see no reason why the PS4 and PS3 can't.

Mark.

Re: Ensuring RPKI ROAs match your routing intent

[Alex Band]

Hi Adam,

> On 25 Jun 2020, at 16:55, Adam Thompson  wrote:
> 
> So in the ARIN world, Krill only works with "delegated" RPKI, not "hosted" 
> RPKI - do I understand that correctly?

Krill is RPKI Certificate Authority software to run Delegated RPKI under one or 
multiple RIRs simultaneously. It’s an all-in choice, so you would choose 
Delegated instead of Hosted.

> If so, are there any plans to allow Krill's analytics and rules to monitor 
> ARIN Hosted RPKI ROAs?

That’s not possible, as Krill can only monitor its own ROAs and not ones that 
are published elsewhere. Perhaps BGP Alerter is a solution for you:

https://github.com/nttgin/BGPalerter 

Cheers,

Alex


> -Adam
> 
> Adam Thompson
> Consultant, Infrastructure Services
> 
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
> 
> From: NANOG  on behalf of 
> Alex Band 
> Sent: Thursday, June 25, 2020 8:31:52 AM
> To: Nanog
> Subject: Ensuring RPKI ROAs match your routing intent 
>  
> Hi everyone,
> 
> Over the last two years NLnet Labs has been working on free, open source RPKI 
> software and research for the community, supported by the RIPE NCC Community 
> Projects Fund, Brazilian NIR NIC.br and Asia Pacific RIR APNIC. I have an 
> update that we’d like to share.
> 
> When creating a ROA in RPKI, it can have an effect on one or more BGP 
> announcements, making them either Valid, Invalid or NotFound. Understanding 
> what exactly determines these three states is not immediately obvious, 
> especially in the beginning.
> 
> At times, this can make creating ROAs a bit of a shot in the dark. I’ve seen 
> several examples in the past where an operator created a ROA in their RIR 
> Portal, waited for it to be published and then checked in services like 
> BGPMon or the HE BGP Toolkit to see if everything turned out as expected. 
> 
> This is why, during my time at the RIPE NCC, we put a lot of work into making 
> it immediately obvious what the effect of a ROA is going to be on the BGP 
> announcements with your address space. Several RIRs have followed in these 
> footsteps since. 
> 
> I presented on this journey at NANOG 63 in 2015:
> https://archive.nanog.org/meetings/abstract?id=2500
> 
> Now, in my new adventure at NLnet Labs, we’ve gotten the same team together 
> to make simple, intuitive ROA management for Delegated RPKI available for 
> everyone, seamlessly across RIR regions. 
> 
> With Krill 0.7.1 ‘Sobremesa’ you can easily create and maintain ROAs in a 
> user interface that incorporates all of the best practices and lessons 
> learned over the last 10 years and monitor them in ways never before 
> possible, such as through Prometheus. 
> 
> Blog post with details:
> http://link.medium.com/1SsTJSAvB7
> 
> All the best,
> 
> Alex