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
Site dedicated mainly to internetworking. The goal is to share experiences, teach IP, IPv6. Talk about Linux, IP services, servers, promote IPv6 adoption, routing protocols, security and in some cases just some thoughts. Keywords: linux, cisco, ospf, bgp, eigrp, ip, ipv6, sla, link, routers, routings, telco, telecommunications, security, ipv4
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
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!
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.
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].
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].
“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:
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.
The video below shows the IPv6 deployment for the LACNIC region using a Bar Chart Race format
Made with https://flourish.studio/
Problem: