IPv6 Deployment - LACNIC region

The video below shows the IPv6 deployment for the LACNIC region using a Bar Chart Race format

Made with https://flourish.studio/

Solved: Finder on MAC does not find any files in its searches

Problem:

   Finder can't find files when searching.

Solution:

   I know there are many solutions, many with spotlight in system preferences, but the one that worked for me was to open a terminal window and run/execute:

  #sudo mdutil -E /

    I hope this is useful

Solved: nping - libnsock mksock_bind_addr(): Bind to 2001:db8:1::1:0 failed (IOD #1): Cannot assign requested address (99)

 Problem:

  When using nping (which comes with nmap) we receive the message:

libnsock mksock_bind_addr(): Bind to 2001:db8:1::1:0 failed (IOD #1): Cannot assign requested address (99)

Current situation:

  The issue is that nping can not bind to the IP 2001:db8:1::1

Solution:

  There could be many different solutions, I'm only going to mention one.  What I did was to create a logical interface (tunnel type) with the IPv6 address I was needing (2001:db8:1::1). Here you have the commands.

ip tuntap add mode tun dev tun1

ip -6 addr add 2001:db8:1::1 dev tun1

ifconfig tun1 up

Finally, you could execute something like:

nping -6 -S 2001:db8:1::1 --tcp-connect -c 2 -p 53 <ipv6_dest> --source-mac 00:50:XX:XX:XX:35  --dest-mac 2c:XX:XX:XX:44:20

Hope this is useful

Solved: Closing connection because of an I/O error in FRR - at least in Ubuntu

 If you are getting this message in FRR:

Closing connection because of an I/O error in FR

The solution is straight forward. You have to compile FRR with this flag:

--enable-systemd

So, it would be something like:

./configure \

    --prefix=/usr \

    --includedir=\${prefix}/include \

    --enable-exampledir=\${prefix}/share/doc/frr/examples \

    --bindir=\${prefix}/bin \

    --sbindir=\${prefix}/lib/frr \

    --libdir=\${prefix}/lib/frr \

    --libexecdir=\${prefix}/lib/frr \

    --localstatedir=/var/run/frr \

    --sysconfdir=/etc/frr \

    --with-moduledir=\${prefix}/lib/frr/modules \

    --with-libyang-pluginsdir=\${prefix}/lib/frr/libyang_plugins \

    --enable-configfile-mask=0640 \

    --enable-logfile-mask=0640 \

    --enable-snmp=agentx \

    --enable-multipath=64 \

    --enable-user=frr \

    --enable-group=frr \

    --enable-vty-group=frrvty \

    --with-pkg-git-version \

    --enable-systemd

    --with-pkg-extra-version=-MyOwnFRRVersion

you can follow those instructions and adding my previous solution:

http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-ubuntu2004.html

Tiny script: how to get the RRSIG DNS records with python3

 (I guess there are many other ways to do this, even more elegant)

import dns.resolver
domain='lacnic.net'
domain = dns.name.from_text(domain)
request = dns.message.make_query(domain, dns.rdatatype.ANY)
response = dns.query.tcp(request,'8.8.8.8')
#print(response)

for item in str(response).splitlines( ):
  if 'RRSIG' in item: print (item)

My review about coin.space (in summary, not recommended)

 Hello there,

  I know many of you are looking for good BTC wallets, good cryptocurrency fees and so on.

  Unfortunately I can not tell you which one is the best or the cheapest, but I can tell you a real BAD one: coin.space

  This site (coin.space) starts charging “normal” fees for sending money, however, they start increasing the fee ONLY for certain accounts, not all of them.

  I will tell you a very simple test I performed from the very same computer, at the very same time.

• I opened two different browsers (Chrome & Firefox)
• In one browser I tried to send money using an “old coin.space” account
• In the other browser I tried to send money using a very new coin.space account
• Trying to send about usd 50, for the “old account” it wanted to charge about usd 12
• Trying to send about usd 50, for the “new account” it wanted to charge about  use 4

  What do you think?.., sorry coin.space but I had to publish this.

Thanks

The sad tale of the ISP that didn’t deploy IPv6

Once upon a time in the not so distant past, a large ISP dominated a country’s 

telecommunications market and felt powerful and without competition. Whenever someone 

needed to log on to the 

Internet they would use their services. Everyone envied their market penetration.

This large ISP, however, had never wanted to deploy IPv6 because they thought their stock

 of IP addresses was enough and saw no indicator telling them that they needed the new 

protocol.

During the course of those years, another smaller ISP began implementing IPv6 and slowly 

began to grow, as they realized that the protocol did indeed make a difference in the eyes of their 

clients and that it was helping them win over new users.

The small ISP’s market penetration continued to grow, as did their earnings and general respect

 for their services. As they grew, it became easier for them to obtain better equipment, traffic 

and interconnection prices. Everything was going very well. The small ISP couldn’t believe that

something as simple as deploying IPv6 could be paying off so spectacularly. Their customers

 told them their needs included running VPNs and holding conference calls with partners in 

other parts of the world, and that their subsidiaries, customers and business partners in Europe

 and Asia had already adopted IPv6.

Despite being so powerful, the large ISP began experiencing internal problems that were 

neither billing nor money related. Sales staff complained that they were having trouble closing 

many deals because customers had started asking for IPv6 and, although their ISP was so

 large and important, they simply did not have IPv6 to offer. Both corporate customers and 

residential users were asking for IPv6; even major state tenders were requiring IPv6.

When this started happening, the Sales Manager complained to the Products, Engineering and 

Operations departments. The latter were left speechless and some employees were let go by 

the company. In the end, Sales did not care where the fault lay – they were simply unable to 

gain new customers. Realizing that they were losing customers, some of the salespeople 

accepted job offers at the small ISP who was looking to grow their staff as they could now 

afford the best sales force. 

Then the same thing happened with the larger ISP’s network manager, an expert who knew 

a lot about IPv6 but who had been unable to overcome the company’s bureaucracy and bring

 the new protocol into production. Logically, the network manager was followed by his trusted 

server administrator and head of security. The large ISP couldn’t believe what was happening

 right before their very eyes. The sales force hired by the smaller ISP (those who used to 

work for the large ISP) brought with them their huge customer base, all of them potential prospects.

A stampede of the large ISP’s clients was on the way. The months went by and the smaller

 ISP was no longer simply offering Internet access – its Data Center had grown, major 

companies brought in new cache servers and much more. They were now offering co-location, 

hosting, virtual hosting, voice and video, among many other services.

When the large provider decided to deploy IPv6, it had to do so very quickly. Things went 

wrong; many errors were made. In addition, certain consultants and companies took 

advantage of their problems and charged higher rush fees. Network downtime increased,

 as did the number of calls to the call center. The large ISP’s reputation started to crumble.

As expected, in the end, everyone who was part of this story – clients and providers alike – 

ended up deploying IPv6. Some ended up happier than others, but everyone adopted IPv6

 on their networks.

By Alejandro Acosta