Showing posts with label ipv6. Show all posts
Showing posts with label ipv6. Show all posts

Monday, December 4, 2023

How to create an IPv6 route to null/blackhole in Linux

 Case:

    How to create an IPv6 route to null/blackhole in Linux

Command:

   ip -6 route add blackhole fd00:12:34::0/48




I hope it is useful

Thursday, July 6, 2023

Google returns: 403. That's an error. Your client does not have permission to get URL / from this server. That's all we know.

 Introduction:

   You want to do a google search and the page returns: "403. That’s an error.

   Your client does not have permission to get URL / from this server. That's all we know."







In my case I was using an IPv6 tunnel with Hurricane Electric, specifically the /64 that they deliver in the tunnels.


Solution?

    Ask Hurricane Electric at the portal for a /48 routed. That's it! Then I removed the old /64 prefix from the router's SLAAC, leaving only a /64 belonging to the /48.


Good luck!

Thursday, March 16, 2023

A Look at LACNIC’s IPv6-Only Members

Introduction

This paper seeks to analyze the announcement and status of the prefixes held by organizations known as IPv6-only LACNIC members. These are organizations that have received IPv6 prefixes, that may or may not have received an autonomous system (ASN), and that have not been assigned an IPv4 prefix by LACNIC. The results of this analysis will help us improve our understanding of the uses and needs of our members across the region.


Information sources used in this analysis

The source of information used in this analysis was LACNIC whois, with data obtained throughout the month of January 2023. This information only includes those members who have been assigned IPv6 but not IPv4 resources by LACNIC. They may or may not have been assigned an autonomous system number.


Data processing

Python3 on a Jupyter notebook. We used the public APIs of LACNIC and RIPE NCC.


LACNIC WHOIS


RIPE NCC API


APNIC IPv6 Penetration by ASN


LACNIC’s delegated-extended File:


Findings

We found 483 organizations that are considered IPv6-only LACNIC members, which we divided into:


            IPv6-only members with ASN: 343 members


            IPv6-only members without ASN: 140 members




Results for the 483 IPv6-only members (with and without ASN):


An analysis of the 483 members allowed us to obtain the following information:


– 261 announce the entire or a portion of the prefix


– 208 announce the entire prefix they received from LACNIC


– 53 announce a portion of the prefix they received from LACNIC


– 222 do not announce the prefix




Results for the 343 IPv6-only members with at least one ASN:


A total of 343 of the 483 IPv6-only members have at least one ASN (71%).


Out of the 343 members that have an ASN:


                        163 announce the prefix (47.52%)


120 announce the entire IPv6 prefix (73.61%)


43 announce a portion of the IPv6 prefix (26.38%)


180 do not announce the IPv6 prefix (52.48%)





Results for the 140 IPv6-only members without an ASN:


A total of 140 of the 483 IPv6-only members do not have an ASN (29%).


Out of these 140 IPv6-only members with no ASN:


98 announce the prefix (70%)


82 announce the entire prefix (83.67%)


16 announce a portion of the prefix (16.32%)


42 do not announce the prefix (30%)





What can we conclude from the charts above?

The first thing that stands out is that IPv6-only members without an ASN have 23% more announcements than LACNIC members who do have an ASN. In other words, these members have asked another organization to announce their prefix.

In both cases, the number of unannounced prefixes is very high, and it might be interesting to find out whether there is a reason for this. 

It is particularly striking that the percentage of partial announcements is almost identical (11% of members with an ASN and 12% of members without an ASN).

Trying to identify whether the ASNs have IPv6 traffic

Knowing that there are 343 ASNs with assigned IPv6 prefixes and considering that these are also IPv6-only members, one can presume that they must have “medium high” IPv6 traffic.  Therefore, we analyzed each autonomous system to determine its IPv6 traffic on 23 January 2023.


How do we find out if an ASN has IPv6 traffic?

As many of you know, APNIC has been measuring IPv6 traffic for each ASN for many years. You can learn more about these studies here: https://stats.labs.apnic.net/ipv6


Based on the above, we wanted to find out if the known ASNs of IPv6-only LACNIC members actually had IPv6 traffic (beyond announcing their prefix). 


Unfortunately, we were unable to obtain information for 274 (79.88%) of the 343 autonomous systems that were analyzed. However, it is important to note that this does not necessarily mean that they have not deployed IPv6, but that the traffic generated is very low and does not appear in the measurements by APNIC. A total of 32 ASNs were reported with 0% IPv6 traffic and 1 ASN with 88% IPv6 traffic.


Are our IPv6-only members actually IPv6-only?

Finally, we wanted to find out if our members (IPv6-only with an ASN) are truly as IPv6-only as their name implies.


For this particular case, we relied on the RIPE NCC API to obtain the information presented below.


Out of the 343 IPv6-only members with at least one ASN:


– A total of 540 prefixes were being announced (including v4 and v6)


                        IPv4 announcements: 220


                        IPv6 announcements: 320


                        In IPv4 announcements, the average prefix length is: 23.56


                        In IPv6 announcements, the average prefix length is: 38.09


– 66 members “became” DualStack, i.e., the ASN announces both IPv4 and IPv6


– 90 members announce IPv6 only


– 27 members announce IPv4 only


– 160 do not announce any prefix


And to which RIR do the IPv4 prefixes announced by IPv6-only LACNIC members belong?


LACNIC ARIN RIPE NCC AFRINIC APNIC

28 166 17 9 0






Sankey Diagram – A Look at LACNIC’s IPv6-Only Members




Conclusions

Results suggest that, while a significant number of LACNIC members consider themselves to be IPv6-only, we observed that more than 50% of these members have not started announcing their IPv6 prefix. At the same time, we noticed that many of those who have deployed IPv6 continue to use IPv4. This means that, although in recent years IPv6 adoption has grown in the region, there is still a long way to go to achieve widespread IPv6 deployment. In any case, it is important to continue to monitor the adoption of the new protocol.


Finally, being an IPv6-only LACNIC member also allows an organization to participate in the Internet ecosystem.

Thursday, February 24, 2022

Why Is IPv6 So Important for the Development of the Metaverse?

 By Gabriel E. Levy B. and Alejandro Acosta

Over almost half a century, the TCP/IP protocols have helped connect billions of people.

Since the creation of the Internet, they have been the universal standards used to transmit information, making it possible for the Internet to function[3].

The acronym ‘IP’ can refer to two different but interrelated concepts. The first is a protocol (the Internet Protocol) whose main function is to be used in bidirectional (source and destination) data transmission based on the Open System Interconnection (OSI) standard[4]The second possible reference when talking about IP involves the assignment of physical addresses in the form of numbers known as ‘IP Addresses’. An IP address is a logical and hierarchical identifier assigned to a network device that uses the Internet Protocol (IP). It corresponds to the network layer, or layer 3 of the OSI model.

IPv4 refers to the fourth version of the Internet Protocol, a standard for the interconnection of Internet-based networks which was implemented in 1983 for the operation of ARPANET and its subsequent migration to the Internet.[5].

IPv4 uses 32-bit addresses, the equivalent of 4.3 billion unique numbering blocks, a figure that back in the 80s appeared to be inexhaustible. However, thanks to the enormous and unforeseen growth of the Internet, by 2011 the unexpected had happened: IPv4 addresses had been exhausted[6].

IPv6 as a solution to the bottleneck

To address the lack of available address resources, the engineering groups responsible for the Internet have resorted to multiple solutions, ranging from the creation of private subnets so that multiple users can connect using a single address, to the creation of a new protocol called IPv6 which promises to be the definitive solution to the problem and which was officially launched on 6 June 2012[7]:

“Anticipating IPv4 address exhaustion and seeking to provide a long-term solution to the problem, the organization that promotes and develops Internet standards (the Internet Engineering Task Force or IETF) designed a new version of the Internet Protocol, specifically version 6 (IPv6), with provides almost limitless availability based on a the use of 128-bit addresses, the equivalent to approximately 340 undecillion addresses”**[[8]**.

It should be noted, however, that the creation of the IPv6 protocol did not anticipate a migration or shift from one protocol to another. Instead, a mechanism was designed to allow both protocols to coexist for a time.

To ensure that the transition would be transparent to users and to allow a reasonable amount of time for vendors to incorporate the new technology and for Internet providers to implement the new version of the protocol in their own networks, along with the IPV6 protocol itself, the organization responsible for Internet protocol standardization — the IETF — designed a series of transition and coexistence mechanisms.

“Imagine this is a weight scale where the plate carrying the heaviest weight currently represents IPv4 traffic. However, little by little and thanks to this coexistence, as more content and services become available over IPv6, the weight of the scale will shift to the other plate, until IPv6 traffic outweighs IPv4. This is what we call the transition”**[9]**.

If both protocols (IPv4 and IPv6) are available, IPv6 is preferred by design. This is why the balance shifts naturally, depending on multiple factors and without us being able to determine how long IPv4 will continue to exist and in what proportion. If one had a crystal ball, one might say that IPv6 will become the dominant protocol in three or four years, and that IPv4 will disappear from the Internet — or at least from many parts of the Internet — in the same timeframe”[10].

Without IPv6 there may be no Metaverse

Metaverses or metauniverses are environments where humans interact socially and economically through their avatars in cyberspace, which is an amplified metaphor for the real world, except that there are no physical or economic limitations[11].

“You can think about the Metaverse as an embodied Internet, where instead of just viewing content — you are in it. And you feel present with other people as if you were in other places, having different experiences that you couldn’t necessarily have on a 2D app or webpage.” Mark Zuckerberg, Facebook CEO**[12]**.

The Metaverse necessarily runs on the Internet, which in turn uses the Internet Protocol (IP) to function.

The Metaverse is a type of simulation where avatars allow users to have much more immersive and realistic connections by displaying a virtual universe that runs online. This is why it is necessary to ensure that the Metaverse is immersive, multisensory, interactive, that it runs in real time, that it allows each user to be precisely differentiated, and that it deploys simultaneous and complex graphic tools, among many other elements. All this would be impossible to guarantee with the IPv4 protocol, as the number of IP addresses would not be enough to cover each connection, nor would it be possible to guarantee that technologies such as NAT would function properly.

Key elements:

  • IPv6 is the only protocol that can guarantee enough IP resources to support the Metaverse.
  • IPv6 avoids the use of NAT mechanisms that would create technological difficulties for the deployment of the Metaverse.
  • IPv6 links have lower RTT delay than IPv4 links, and this allows avatar representations, including holograms, to be displayed synchronously.
  • Considering the huge amount of data involved in the deployment of the Metaverse, it is necessary to ensure the least possible data loss. This is why IPv6 is the best option, as evidence shows that data loss is 20% lower when using IPv6 than when using IPv4[13].

The role of small ISPs

Considering that small ISPs are responsible for the connectivity of millions of people across Latin America and that, as previously noted, they are largely responsible for reducing the digital divide[14], it is very It is important for these operators to accelerate their migration/transition to IPv6, not only to remain competitive in relation to larger operators, but also to be able to guarantee their users that technologies such as the Metaverse will work on their devices without major technological headaches.

In conclusion, while the true scope of the Metaverse remains to be seen, its deployment, implementation, and widespread adoption will be possible thanks to the IPv6 protocol, a technology that has provided a solution to the availability of IP resources, avoiding the cumbersome network address translation (NAT) process, improving response times, reducing RTT delay, and decreasing packet losses, while at the same time allowing simultaneous utilization by an enormous number of users.

All of the above leads us to conclude that the Metaverse would not be possible without IPv6.

Disclaimer: This article contains a review and analysis undertaken in the context of the digital transformation within the information society and is duly supported by reliable and verified academic and/or journalistic sources, which have been delimited and published.

The information contained in this journalistic and opinion piece does not necessarily represent the position of Andinalink or of the organizations commercially related with Andinalink.

[1] Andinalink article: Metaversos y el Internet del Futuro (Metaverses and the Internet of the Future)
[2] Andinalink article: Metaversos: Expectativas VS Realidad (Metaverses: Expectations vs Reality)
[3] In the article titled: El agotamiento del protocolo IP (The Exhaustion of the IP Protocol) we explain the characteristics of the TCP protocol. 
[4] Standard reference document on the OSI connectivity model
[5] The article titled: ¿Fue creada Arpanet para soportar una guerra nuclear? (Was Arpanet Created to Withstand a Nuclear War?) details the features and history of Arpanet.
[6] LACNIC document on the Phases of IPv4 Exhaustion
[7] Document published by the IETF about World IPv6 Launch on its sixth anniversary
[8] Guide for the Transition to IPv6 published by the Colombian Ministry of Information and Communications Technology
[9] Guide for the Transition to IPv6 published by the Colombian Ministry of Information and Communications Technology
[10] Guide for the Transition to IPv6 published by the Colombian Ministry of Information and Communications Technology
[11] Andinalink article on Metaverses
[12] Mark in the Metaverse: Facebook’s CEO on why the social network is becoming ‘a metaverse company: The Verge Podcast
[13] Analysis by Alejandro Acosta (LACNIC) of the impact of IPv6 on tactile systems
[14] Andinalink article: Los WISP disminuyen la brecha digital (WISPs Reduce the Digital Divide)

Friday, June 25, 2021

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/

Wednesday, May 19, 2021

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

Friday, September 6, 2019

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

Friday, July 13, 2018

How to run Flask framework to listen in both IPv4 and IPv6 (DualStack)

Issue:
  How to run Flask framework to listen in both IPv4 and IPv6 (DualStack)

Answer:
  app.run(host='::',port=5005)



Start your machine learning or AI journey with Runpod. If you need affordable GPU rental , RunPod has the lowest prices. Rent a NVIDIA RTX A6000 with 48GB VRAM, or other models like NVIDIA 3090.

Monday, August 21, 2017

My humble results. Testing ping to loopback using v4 and v6

Hello there,
  Regarding RTT v4 vs v6 I did something "interesting" recently, would like to know your thoughs.
  If you ping6 your loopback (let´s say 1000 packets) interface with Windows or Linux, v6 is faster.
  Now try the same on MAC (El capitan for example).., v6 is 20-25% slower.
  I did the above with many devices (and asked some friends) and the behavior was pretty much the same.


MAC:
--- 127.0.0.1 ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.037/0.098/1.062/0.112 ms

--- ::1 ping6 statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.058/0.120/0.194/0.027 ms




Linux:
--- 127.0.0.1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 98999ms
rtt min/avg/max/mdev = 0.015/0.021/0.049/0.007 ms

--- ::1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99013ms
rtt min/avg/max/mdev = 0.019/0.031/0.040/0.004 ms



Windows 10:

Ping statistics for ::1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms



Ping statistics for 127.0.0.1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 4ms, Average = 0ms



Bye,


wetheitteam.com
Where to order pain Relief without prescription
vivo v15 pro

Monday, February 29, 2016

Read a BGP live stream from CAIDA

Objective
  Read a BGP live stream from CAIDA and insert them into a BGP session

What do we need
  bgpreader from the bgpstream core package provided by Caida
  bgp_simple.pl obtained in github

Overview
  We will read the BGP live stream feed using bgpreader, then the standard output of it will be redirected to a pipe file (mkfifo) where a perl script called bgpsimple will be reading this file. This very same script will established the BGP session against a BGP speaker and announce the prefixes received in the stream.

LAB Topology
  The configuration was already tested in Cisco & Quagga
  The BGP Speaker (Cisco/Quagga) has the IPv4 address 192.168.1.1
  The BGP Simple Linux box has the IP 192.168.1.2

How does it works?
  bgpreader has the ability to write his output in the -m format used by libbgpdump (by RIPENCC), this is the very same format bgpsimple uses as stdin. That's why myroutes is a PIPE file (created with mkfifo).

Steps:  

INSTALL BGP READER - UBUNTU 15.04

First install general some packages:
apt-get install apt-file libsqlite3-dev libsqlite3 libmysqlclient-dev libmysqlclient
apt-get install libcurl-dev libcurl  autoconf git libssl-dev
apt-get install build-essential zlib1g-dev libbz2-dev
apt-get install libtool git
apt-get install zlib1g-dev

Also intall wandio
wandio-1.0.3
git clone https://github.com/alistairking/wandio

./configure

cd wandio
./bootstrap.sh
./configure && ./make && ./make install
wandiocat http://www.apple.com/library/test/success.html

to test wandio:
wandiocat http://www.apple.com/library/test/success.html

Download bgp reader tarball from:
https://bgpstream.caida.org/download

#ldconfig (before testing)

#mkfifo myroutes

to test bgpreader:
./bgpreader -p caida-bmp -w 1453912260 -m
(wait some seconds and then you will see something)

# git clone https://github.com/xdel/bgpsimple


Finally run everything
In two separate terminals (or any other way you would like to do it):

./bgpreader -p caida-bmp -w 1453912260 -m > /usr/src/bgpsimple/myroutes
./bgp_simple.pl -myas 65000 -myip 192.168.1.2 -peerip 192.168.1.1 -peeras 65000 -p myroutes

One more time, what will happen behind this?
bgpreader will read an online feed from a project called caida-bmp with starting timestamp 1453912260 (Jan 27 2016, 16:31) in "-m" format, It means a libbgpdump format (see references). The stardard output of all this will be send to the file /usr/src/bgpsimple/myroutes which is a "pipe file". At the same time, bgp_simple.pl will create an iBGP session againts peer 192.168.1.1/AS65000 (a bgp speaker such as Quagga or Cisco). bgp_simple.pl will read myroutes files and send what it seems in this file thru the iBGP Session.

Important information
- The BGP Session won't be established until there is something in the file myroutes
- eBGP multi-hop session are allowed
- You have to wait short time (few seconds) until bgpreaders start to actually see something and bgp_simple.pl starts to announce to the BGP peer

References / More information:
-Part of the work was based on:
http://evilrouters.net/2009/08/21/getting-bgp-routes-into-dynamips-with-video/

- Caida BGP Stream:
https://bgpstream.caida.org/

- bgpreader info:
https://bgpstream.caida.org/docs/tools/bgpreader

- RIPE NCC libbgpdump:
http://www.ris.ripe.net/source/bgpdump/

- Introduction of "Named Pipes" (pipe files in Linux):
http://www.linuxjournal.com/article/2156

Wednesday, February 17, 2016

Animation: The sad tale of the ISP that did not deploy IPv6


Hello,
  The following animation is based on the story called: "The sad tale of the ISP that didn't deploy IPv6" [1]. Hope you enjoy it:


[1] http://portalipv6.lacnic.net/en/the-sad-tale-of-the-isp-that-didnt-deploy-ipv6/



Friday, January 1, 2016

Virtualbox in Windows. Bridge adapter + IPv6 not working

Introduction:
  When trying to use IPv6 in Virtualbox inside a guest where the adapter is bridge to the wireless interface of the host, the VM does SLAAC correctly but HTTP or ping6 does not work.

Solution:
  To solve this issue just reinstall/repair your current Virtualbox instalattion (version 5) adding the following parameters to the installer: "-Win.exe -msiparams NETWORKTYPE=NDIS5"

The result would be something like:

G:\>VirtualBox-5.0.12-104815-Win.exe -msiparams NETWORKTYPE=NDIS5

So, you cannot double click on the installer, you need to do it from command line with admin privileges.

Workaround:
  The problem is only with the bridging to the wireless adapter, you, if possible, you could bridge to a non-wireless interface and IPv6 should work perfectly.

References:
https://www.virtualbox.org/ticket/14457

Good luck,


Tuesday, May 26, 2015

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

Monday, January 26, 2015

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.

Monday, December 8, 2014

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()

Saturday, October 18, 2014

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/