IPv6 Song presented during Lacnic23 (Lima, Peru) - IPv6 Latin American Forum

(note that you can turn on captioning if you wish)

Antonio Esguerra: Head Engineer
Michael Schulze: Co-producer
Eidan Molina: Co-producer. Composer.
Music and Lyrics by Eidan Molina
Agrupacion de produccion: Fifth Floor Studios
Idea: Alejandro Acosta

Solution to quagga vtysh "Exiting: failed to connect to any daemons."

Description:
   When you run the command in the linux shell vtysh to connect to the quagga daemons (such as bgpd, ospfd, etc) returns  the following error "Exiting: failed to connect to any daemons"

Just like this:

alejandro @ miserver: ~ $ vtysh -d bgpd
Exiting: failed to connect to any daemons.

alejandro @ miserver: ~ $ vtysh
Exiting: failed to connect to any daemons.


Solution:
   The solution is to add the user that is executing vtysh to the quagga group. To do this edit the /etc/group file.
   After editing /etc/group should be something like:

quagga:x:1003:alejandro

You can specify multiple users doing:

quagga:x:1003:alejandro, john


   This is necessary because vtysh tries to connect to the daemons using UNIX domain sockets and not all users (for security reasons) have access to these sockets.

Another solution:
   Another solution might be during the compilation phase where you can specify the linux/unix group for sockets mentioned above. Example:

./configure --enable-vty-group = group


   Good luck, I hope this helped,

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.

Python Script: Probably useless but functional IPv6 Network scanner

Below is the code of what is probably useless but a functional IPv6 host scanner written in Python using threading.

To perform a regular (brute force) network scans in an IPv6 Network is almost impossible it can take over 5.000 years to finish.

This project was purely academic and I just wanted to learn about threading in Python.

This software is not recommended for general usage.....

This  script  will call the OS to actually perform the ping

This software receives two parameters:
a) Prefix to scan in the format 2001:db8::/64 (subnet, not host)
b) Number of simultaneous processes it can run (MAXPINGS)

One more time it was purely academic stuff but hopefully it can make your day

Finally, AFAIK nmap does not yet support IPv6 network scan.

The code written in python3:

--- cut here ---

#!/usr/bin/python3

import threading
import sys
import ipaddress
import subprocess
import time

CURRENTPINGS=0 # Number of simultaneous ping at a time

def DOPING6(IPv6ADDRESS):
  global MAXPINGS, CURRENTPINGS
  CURRENTPINGS+=1
  CMD="ping6 -c 3 "+str(IPv6ADDRESS) + " 2> /dev/null > /dev/null"
  return_code = subprocess.call(CMD, shell=True)
  if return_code == 0:  #If ping was succesful
    print (IPv6ADDRESS," is alive")
 
  CURRENTPINGS-=1
 
def main():
  global MAXPINGS, CURRENTPINGS
  if len(sys.argv) != 3: #Validate how many parameters we are receiving
    print("  Not enough or too many parameter")
    print("  Usage: ./scanipv6.py IPv6Prefix/lenght MAXPINGS")
    print("  Example: ./scanipv6.py 2001:db8::/64 20")
    print("  Prefix lenght can be between 64-128")
    print("  MAXPINGS corresponds to how many pings will be running at the same time")
    exit()

  SUBNET,MASK=sys.argv[1].split("/")
  MAXPINGS=int(sys.argv[2])

  for addr in ipaddress.IPv6Network(sys.argv[1]):  #Let's loop for each address in the Block
    ping_thread=threading.Thread(target=DOPING6,args=(addr,))

    while CURRENTPINGS >= MAXPINGS: # With this while we make it possible to run max simultaneous pings
      time.sleep(1)  # Let's wait one second before proceeding
      #print ("Interrumping...., CURRENTPINGS > MAXPINGS") #Uncomment this line just for debugging

    ping_thread.start()

main()

$GENERATE A records using BIND. Match forward and rDNS

Hi,
This post is very short but perhaps very useful. There is less documentation on the Internet than expected.

Objective: 
a) Set the reverse DNS and forward DNS match for a / 24 in BIND9 using $GENERATE.

Requirements: 
- A  /24 network (of course, you can adapt the example to other networks)
- BIND9
- We will use A and PTR records

Example: 
Network: 192.168.30.0/24
Domain: example.com

Let's make the rDNS for 192.168.30.X resolved to: X.client.example.com
Similarly, X.client.example.com to resolve to 192.168.30.X

It would be like this:
192.168.30.1 ---> 1.client.example.com
192.168.30.2 ---> 2.client.example.com
192.168.30.3 ---> 3.client.example.com
1.client.example.com ---> 192.168.30.1
2.client.example.com ---> 192.168.30.2
3.client.example.com ---> 192.168.30.3
(Etc)

Steps: 
We create reverse zone in /etc/bind/named.conf.

a) The reverse zone:

zone "30.168.192.in-addr.arpa" {
type master;
file "30.168.192.in-addr.arpa.db";
allow-query {any; };
};


After that, then in file 30.168.192.in-addr.arpa.db place the following: 

$TTL    86400 ; 24 hours, could have been written as 24h or 1d

@  1D  IN        SOA localhost.     hostmaster.example.com. (

                              2002022401 ; serial

                              3H ; refresh

                              15 ; retry

                              1w ; expire

                              3h ; minimum

                             )

; Name servers for the zone - both out-of-zone - no A RRs required

                        NS      localhost.

$GENERATE 1-255 $ PTR $.client.example.com.

b) The forward DNS is doing the following in the client.example.com zone file: 

$TTL    86400 ; 24 hours, could have been written as 24h or 1d

@  1D  IN        SOA localhost.     hostmaster.example.com. (

                              2002022401 ; serial

                              3H ; refresh

                              15 ; retry

                              1w ; expire

                              3h ; minimum

                             )

; Name servers for the zone - both out-of-zone - no A RRs required

                        NS      localhost.

$GENERATE 1-255.client.example.com $ A 192.168.30.$

Testing: 
#dig -x 192.168.30.3 (reverse dns) 
#dig 3.cliente.ejemplo.com (forward dns) 

P.S. As usual there can be more than way of doing this kind of things.

Is there any relationship regarding the deployment of IPv6 between entities with ASNs of 16 and 32 bits?

Hi,
  Today this came to my mind and fortunately I knew the data existed and to locate the answer was more or less simple. I've been reviewing some data from APNIC (* 1) for several weeks (always focused on the area of ​​coverage Lacnic).
  APNIC stores a percentage value per ASN called called ipv6capable, basically is a number that indicates what percentage of an ASN has capacity for IPv6. They have another variable called ipv6 preferred but we will not talk about it right now.
  Going back to my micro study: I took a sample for three days: 11, 12 and October 15, 2014

My results (for ipv6capable) were:

Day October 15 (Wednesday)
1.34% in ASNs of 16 bits
1.12% in ASNs of 32 bits
1.26% in all ASNs
----
Day October 11 (Saturday)
1.34% in 16-bit ASN
1.15% in 32-bit ASN
1.27% all ASN
---
Day October 12 (Sunday)
1.35% in 16-bit
1.12% in 32-bit
1.27% all ASN (ASN 3313)
----

I evaluated about 2050  ASNs of 16-bits  and 1200 ASN of 32 bits. The difference between ipv6capable ASNs 16 and 32 bits is about 0.2, it is certainly a very small number but when it comes to traffic and users on the Internet these numbers represent significant volume.

My humble finding for this study is simple: It seems that there is a *very* slight preference for the deployment of IPv6 in 16-bit ASN.

Regards,

(*1) http://labs.apnic.net/ipv6-measurement/AS/

Old video (but nice): Hitler parady about IPv6