A Practical Improvement in DNS Transport over UDP over IPv6

By Hugo Salgado and Alejandro Acosta

Introduction and problem statement

In this document we want to discuss an existing IETF draft (a working document that may become a standard) that caught our attention. This draft involves two fascinating universes: IPv6 and DNS. It introduces some best practices for carrying DNS over IPv6.

Its title is “DNS over IPv6 Best Practices” and it can be found here.

What is the document about and what problem does it seek to solve?

The document describes an approach to how Domain Name Protocol (DNS) should be carried over IPv6 [RFC8200].

Some operational issues have been identified in carrying DNS packets over IPv6 and the draft seeks to address them.

Technical context

The IPv6 protocol requires a minimum link MTU of 1280 octets. According to Section 5 “Packet Size Issues” of RFC8200, every link in the Internet must have an MTU of 1280 octets or greater. If a link cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.

Successful operation of PMTUD in an example adapted to 1280-byte MTU

Image source: https://www.slideshare.net/slideshow/naveguemos-por-internet-con-ipv6/34651833#2

Using Path MTU Discovery (PMTUD) and IPv6 fragmentation (source only) allows larger packets to be sent. However, operational experience shows that sending large DNS packets over UDP over IPv6 results in high loss rates. Some studies —quite a few years old but useful for context— found that around 10% of IPv6 routers drop all IPv6 fragments, and 40% block “Packet Too Big” messages, making client negotiation impossible. (“M. de Boer, J. Bosma, “Discovering Path MTU black holes on the Internet using RIPE Atlas”)

Most modern transport protocols like TCP [TCP] and QUIC [QUIC] include packet segmentation techniques that allow them to send larger data streams over IPv6.

A bit of history

The Domain Name System (DNS) was originally defined in RFC1034 and RFC1035. It was designed to run over several different transport protocols, including UDP and TCP, and has more recently been extended to run over QUIC. These transport protocols can be run over both IPv4 and IPv6.

When DNS was designed, the size of DNS packets carried over UDP was limited to 512 bytes. If a message was longer than 512 bytes, it was truncated and the Truncation (TC) bit was set to indicate that the response was incomplete, allowing the client to retry with TCP.

With this original behavior, UDP over IPv6 did not exceed the IPv6 link MTU (maximum transmission unit), avoiding operational issues due to fragmentation. However, with the introduction of EDNS0 extensions (RFC6891), the maximum was extended to a theoretical 64KB. This caused some responses to exceed the 512-byte limit for UDP, which resulted in sizes that exceeded the Path MTU and triggered TCP connections, impacting the scalability of the DNS servers.

Encapsulating a DNS packet in an Ethernet frame

Let’s talk about DNS over IPv6

DNS over IPv6 is designed to run over UDP or other transport protocols like TCP or QUIC. UDP only provides for source and destination ports, a length field, and simple checksum. It is a connectionless protocol. In contrast, TCP and QUIC offer additional features such as packet segmentation, reliability, error correction, and connection state.

DNS over UDP over IPv6 is suitable for small packet sizes, but becomes less reliable with larger sizes, particularly when IPv6 datagram fragmentation is required.

On the other hand, DNS over TCP or QUIC over IPv6 work well with all packet sizes. However, running a stateful protocol such as TCP or QUIC places greater demands on the DNS server’s resources (and other equipment such as firewalls, DPIs, and IDS), which can potentially impact scalability. This may be a reasonable tradeoff for servers that need to send larger DNS response packets.

The draft’s suggestion for DNS over UDP recommends limiting the size of DNS over UDP packets over IPv6 to 1280 octets. This avoids the need for IPv6 fragmentation or Path MTU Discovery, which ensures greater reliability.

Most DNS queries and responses will fit within this packet size limit and can therefore be sent over UDP. Larger DNS packets should not be sent over UDP; instead, they should be sent over TCP or QUIC, as described in the next section.

DNS over TCP and QUIC

When larger DNS packets need to be carried, it is recommended to run DNS over TCP or QUIC. These protocols handle segmentation and reliably adjust their segment size for different link and path MTU values, which makes them much more reliable than using UDP with IPv6 fragmentation.

Section 4.2.2 of [RFC1035] describes the use of TCP for carrying DNS messages, while [RFC9250] explains how to implement DNS over QUIC to provide transport confidentiality. Additionally, operation requirements for DNS over TCP are described in [RFC9210].

Security

Switching from UDP to TCP/QUIC for large responses means that the DNS server must maintain an additional state for each query received over TCP/QUIC. This will consume additional resources on the servers and affect the scalability of the DNS system. This situation may also leave the servers vulnerable to Denial of Service (DoS) attacks.

Is this the correct solution?

While we believe this solution will bring many benefits to the IPv6 and DNS ecosystem, it is a temporary operational fix and does not solve the root problem.

We believe the correct solution is ensuring that source fragmentation works, that PMTUD is not broken along the way, and that security devices allow fragmentation headers. This requires changes across various Internet actors, which may take a long time, but that doesn’t mean that we should abandon our efforts or stop educating others about the importance of doing the right thing.

Video: IPv6 LAC Race - May 2014 - Jun 2024

Do you want to know how the evolution of IPv6 has been in LAC? In this video of just a minute you will have your answer #barchartrace #ipv6

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

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!

Bar Chart Race IPv6 Deployment in LAC Region - May 2014 to June 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.

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)

IPv6 Is Not Encrypted but Respects Privacy

To know more About pink line metro route Visit

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: 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

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

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.

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

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

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/

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,

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

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.