Re: Deploying IPv6 XLAT64

> On 27 Sep 2018, at 4:22 am, Matt Hoppes > wrote: > > Thanks... that is what I don't understand: Why is NAT64 such a difficult > concept to put into routers and firewalls? We already do NAT with IPv4 just > fine. It’s not s difficult concept but you need to remember NAT44 breaks stuff a

Re: US based networks suffering from RPKI misconfigurations

> Affected networks might soon (by the end of the year) loose the > ability to talk to Cloudflare networks since they plan to deploy ROV. and then they will clean up their messes until then you can generate a lot of email if it amuses you randy

Rogers AS812 help

Hi NOGers If anyone from Rogers is on, could you please contact me offline? Thanks J~

US based networks suffering from RPKI misconfigurations

Hi, the tables bellow show the number of IPv4 and IPv6 blocks per ASN that are unreachable in an RPKI route origin validating (ROV) environment (this list is filtered for US ASNs based on RIPEstat ASN data). Affected networks might soon (by the end of the year) loose the ability to talk to Clo

Re: ARIN RPKI TAL deployment issues

On Tue, 25 Sep 2018, Job Snijders wrote: >We really need to bring it back down to "apt install rpki-cache-validator" You say this as if no packager has a way to display and perhaps require approval of the license nor any way to fetch something remote as part of the installation process, e.g., t

Re: ARIN RPKI TAL deployment issues

On Sep 26, 2018, at 3:58 PM, Baldur Norddahl mailto:baldur.nordd...@gmail.com>> wrote: This seems silly. Please find a way to make RPKI useful also in the ARIN region. Baldur - RPKI in the ARIN region is useable (by definition, as there are indeed people in the region using it.) The question is

Re: ARIN RPKI TAL deployment issues

ons. 26. sep. 2018 14.57 skrev John Curran : >In the case of ARIN, this does necessitate indemnification in order to > reduce risk exposure to the overall RIR mission. > > Thanks, > /John > > John Curran > President and CEO > ARIN > > Did you buy insurance? It is impossible to be immune from l

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

valdis.kletni...@vt.edu wrote on 9/26/2018 1:44 PM: On Wed, 26 Sep 2018 10:52:07 +0300, Michael Bullut said: Has anyone deployed the aforementioned in your individual networks? A quick test suggests it is quite fast compared with Google's D.N.S. resolvers: *Reply from 1.1.1.1

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

On Wed, 26 Sep 2018 10:52:07 +0300, Michael Bullut said: > Has anyone deployed the aforementioned in your individual networks? A quick > test suggests it is quite fast compared with Google's D.N.S. resolvers: > *Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61* 3ms indicates you're

Re: Deploying IPv6 XLAT64

This document, which is already in the IESG review, may answer your question: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Also take a look into this one: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ Remember that if your enterprise network has app

Re: Deploying IPv6 XLAT64

Thanks... that is what I don't understand: Why is NAT64 such a difficult concept to put into routers and firewalls? We already do NAT with IPv4 just fine. I feel like IPv6 adoption would be much faster if there was a transition mechanism other than dual stacking. Think: Corporate offices.

Re: Deploying IPv6 XLAT64

You can use Jool for both 464XLAT and just NAT64. I've done a workshop on this at the LACNIC meeting this week. See slides 43 and next ones: http://www.lacnic.net/innovaportal/file/3139/1/ipv6-only_v11_16-9.pdf Saludos, Jordi -Mensaje original- De: NANOG en nombre de Matt Hoppes

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

In article <87in2sy5eh@pc8.berlin.quux.de> you write: >quick and dirty: > >jens@screen:~$ dig nanog.org @8.8.8.8 | grep "Query time" >;; Query time: 16 msec >jens@screen:~$ dig nanog.org @1.1.1.1 | grep "Query time" >;; Query time: 3 msec Yeah, that's super reliable: $ drill nanog.org @1.1.1.

Deploying IPv6 XLAT64

Looking at getting into IPv6 here ourselves... one of the big hold ups has been the dual stacking. Can anyone recommend a quality, not ridiculously convoluted to setup, XLAT64 translator that we could run in our network to take the IPv6 to an IPv4 address when the remote server doesn't have 6

Re: ARIN RPKI TAL deployment issues

On 26 Sep 2018, at 11:02 AM, Tony Finch mailto:d...@dotat.at>> wrote: John Curran mailto:jcur...@arin.net>> wrote: From "CA Terms & Conditions APNIC’s Certification Authority (CA) services are provided under t

Re: ARIN RPKI TAL deployment issues

John Curran wrote: > > From > > > "CA Terms & Conditions > > APNIC’s Certification Authority (CA) services are provided under the > following terms and conditions: ... > > • The recipient of any Digital Certificat

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

For Window’s clients, you might want to try out this freeware GRC tool for benchmarking DNS performance: https://www.grc.com/dns/benchmark.htm Cheers -- Yonatan (Yoni) Radzin yrad...@gmail.com > On Sep 26, 2018, at 3:59 AM, Michael Bullut wrote: > > Hi Ross, > > How would you gauge good D

Re: ARIN RPKI TAL deployment issues

On Wed, Sep 26, 2018 at 03:29:33AM -0400, Jared Mauch wrote: > > > > On Sep 26, 2018, at 3:13 AM, John Curran wrote: > > > > On 26 Sep 2018, at 2:09 AM, Christopher Morrow > > wrote: > >> > >> (I'm going to regret posting this later, but...) > >> > >> On Tue, Sep 25, 2018 at 10:57 PM John C

Re: ARIN RPKI TAL deployment issues

Hi, John. On Tue, Sep 25, 2018, 22:56 John Curran wrote: > > Indeed - In the process of complying with a different legal environment, > ARIN sometimes has to behave differently than RIRs that are located > elsewhere... > > [...] > > The significant difference for ARIN is that we operate under a

Re: ARIN RPKI TAL deployment issues

On Wed, Sep 26, 2018 at 6:42 AM Tony Finch wrote: > > Let's Encrypt does not require an agreement from relying parties (i.e. > browser users), whereas ARIN does. > > this was my point, sorry for muddying things. (see 'regret' comment earlier)

Re: ARIN RPKI TAL deployment issues

On 26 Sep 2018, at 9:26 AM, Jared Mauch wrote: >> On Sep 26, 2018, at 7:16 AM, John Curran wrote: >> >> On 26 Sep 2018, at 3:29 AM, Jared Mauch wrote: >>> >>> The process for lets encrypt is fairly straightforward, it collects some >>> minimal information (eg: e-mail address, domain name) and

Re: ARIN RPKI TAL deployment issues

> On Sep 26, 2018, at 7:16 AM, John Curran wrote: > > On 26 Sep 2018, at 3:29 AM, Jared Mauch wrote: >> >> The process for lets encrypt is fairly straightforward, it collects some >> minimal information (eg: e-mail address, domain name) and then does all the >> voodoo necessary. If ARIN w

Re: ARIN RPKI TAL deployment issues

On 26 Sep 2018, at 8:21 AM, Job Snijders mailto:j...@ntt.net>> wrote: ARIN and APNIC go further by having indemnification by parties using information in the CA; in ARIN’s case, this requires an explicit act of acceptance to be legally valid. Are you sure about APNIC? The APNIC TAL is available

Re: ARIN RPKI TAL deployment issues

On Wed, Sep 26, 2018 at 11:07:49AM +, John Curran wrote: > > Let's Encrypt does not require an agreement from relying parties > > (i.e. browser users), whereas ARIN does. > > That is correct; I did not say that they were parallel situations, > only pointing out that the Let’s Encrypt folks al

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

Seems like a good reason to not use Firefox. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: niels=na...@bakker.net To: nanog@nanog.org Sent: Wednesday, September 26, 2018 6:34:44 AM Su

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

* na...@ics-il.net (Mike Hammett) [Wed 26 Sep 2018, 13:14 CEST]: I recommend that eyeball networks don't run any external recursive server for optimal CDN performance. Yes, some CDNs support other methods, but not all. If not all do, then the requirement remains. +1 https://blog.powerdns.com/

Re: ARIN RPKI TAL deployment issues

On 26 Sep 2018, at 3:29 AM, Jared Mauch wrote: > > The process for lets encrypt is fairly straightforward, it collects some > minimal information (eg: e-mail address, domain name) and then does all the > voodoo necessary. If ARIN were to make this request of the developers of > RPKI software,

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

I recommend that eyeball networks don't run any external recursive server for optimal CDN performance. Yes, some CDNs support other methods, but not all. If not all do, then the requirement remains. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX htt

Re: ARIN RPKI TAL deployment issues

On 26 Sep 2018, at 6:42 AM, Tony Finch wrote: > > John Curran wrote: >> On 26 Sep 2018, at 2:09 AM, Christopher Morrow >> mailto:morrowc.li...@gmail.com>> wrote: >>> >>> how is arin's problem here different from that which 'lets encrypt' is >>> facing with their Cert things? >> >> The “Let’s

Re: ARIN RPKI TAL deployment issues

John Curran wrote: > On 26 Sep 2018, at 2:09 AM, Christopher Morrow > mailto:morrowc.li...@gmail.com>> wrote: > > > > how is arin's problem here different from that which 'lets encrypt' is > > facing with their Cert things? > > The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

Jens Link wrote: > > jens@screen:~$ dig nanog.org @8.8.8.8 | grep "Query time" > ;; Query time: 16 msec > jens@screen:~$ dig nanog.org @1.1.1.1 | grep "Query time" > ;; Query time: 3 msec You can use dig -u to get microsecond resolution, e.g. $ dig -u @131.111.8.42 nanog.org | grep time: ;; Quer

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

On Wed, Sep 26, 2018 at 11:28:06AM +0200, Jens Link wrote a message of 14 lines which said: > quick and dirty: Indeed. For instance, the delay depends wether the cache it hot or cold (measuring response time for an authoritative server is easier).

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

Michael Bullut writes: > Hi Ross, > > How would you gauge good DNS performance?  quick and dirty: jens@screen:~$ dig nanog.org @8.8.8.8 | grep "Query time" ;; Query time: 16 msec jens@screen:~$ dig nanog.org @1.1.1.1 | grep "Query time" ;; Query time: 3 msec Jens

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

On Wed, Sep 26, 2018 at 09:21:21AM +0100, Colin Johnston wrote a message of 16 lines which said: > also could use ripe atlas Which embeds clients for ICMP Echo, DNS, NTP, TLS, arbitrary TCP (with some hacks), and, with serious limitations, HTTP.

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

also could use ripe atlas Colin > On 26 Sep 2018, at 09:15, Stephane Bortzmeyer wrote: > > On Wed, Sep 26, 2018 at 10:59:02AM +0300, > Michael Bullut wrote > a message of 192 lines which said: > >> How would you gauge good DNS performance? > > To test {XXX} performance, you use a {XXX} cli

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

On Wed, Sep 26, 2018 at 10:59:02AM +0300, Michael Bullut wrote a message of 192 lines which said: > How would you gauge good DNS performance? To test {XXX} performance, you use a {XXX} client, where XXX = DNS, HTTP, SSH, LDAP, etc.

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

On Wed, Sep 26, 2018 at 10:52:07AM +0300, Michael Bullut wrote a message of 162 lines which said: > Has anyone deployed the aforementioned in your individual networks? > A quick test suggests it is quite fast compared with Google's > D.N.S. resolvers: Well, you don't test a DNS service with I

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

Hi Ross, How would you gauge good DNS performance? Warm regards, Michael. On Wed, 26 Sep 2018 at 10:50, Ross Tajvar wrote: > Do note that ping response times are not a good indicator of DNS > performance. > > On Wed, Sep 26, 2018, 3:48 AM Michael Bullut wrote: > >> Greetings Team, >> >> Has

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

Do note that ping response times are not a good indicator of DNS performance. On Wed, Sep 26, 2018, 3:48 AM Michael Bullut wrote: > Greetings Team, > > Has anyone deployed the aforementioned in your individual networks? A > quick test suggests it is quite fast compared with Google's D.N.S. > res

CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

Greetings Team, Has anyone deployed the aforementioned in your individual networks? A quick test suggests it is quite fast compared with Google's D.N.S. resolvers: *C:\Users\bullutm>ping 1.1.1.1* *Pinging 1.1.1.1 with 32 bytes of data:* *Reply from 1.1.1.1 : bytes=32 time=3ms TT

Re: ARIN RPKI TAL deployment issues

> On Sep 26, 2018, at 3:13 AM, John Curran wrote: > > On 26 Sep 2018, at 2:09 AM, Christopher Morrow > wrote: >> >> (I'm going to regret posting this later, but...) >> >> On Tue, Sep 25, 2018 at 10:57 PM John Curran wrote: >> >> The significant difference for ARIN is that we operate unde

Re: ARIN RPKI TAL deployment issues

On 26 Sep 2018, at 2:09 AM, Christopher Morrow mailto:morrowc.li...@gmail.com>> wrote: (I'm going to regret posting this later, but...) On Tue, Sep 25, 2018 at 10:57 PM John Curran mailto:jcur...@arin.net>> wrote: The significant difference for ARIN is that we operate under a different legal

Re: ARIN RPKI TAL deployment issues

On 26 Sep 2018, at 1:14 AM, Benson Schliesser wrote: > Without venturing too far off topic, can you briefly compare this situation > versus e.g. licensing of open source software? Often, such software is > (apparently) licensed without express agreement - using bundled license > files, comments