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)

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.

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

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

IPv6 & Satellite links: The right solution for rest of the world

Abstract:

 Nowadays, having Internet access is a right. It’s like having electricity or water. Being an extremist, I would even say it’s like oxygen in somehow.

  This small draft tries to summarize a simple combination of technologies that is supposed to be a long term solution to remote places where Internet access if generally difficult to get.

 One of the goals of mankind today should be to offer good and reliable Internet access to everyone, in despite of their location. Our current motivation is oriented to places where a terrestrial link is impossible to find.

 We basically want to mix two good technologies that unfortunately we believe are not working together today: 1) satellite links and 2) IPv6. The first one with its pros and cons -as all kind of technology- is a proven solution. The second one has also proved to be reliable, and is the de facto standard for the near future.

Introduction:

  In the last 13 years of my life I have been working in the satellite link area. Additionally, since 1998 I've been curious about IPv6 but it was not until six years ago that I've really been able to work with it. Finally, I have always been passionate about Internet, communications and freedom of information

As a technical person I have always preferred connections over fiber,  copper or even wireless links (microwave, Wi-Fi, WIMAX, etc.) however these are not always possible, mostly because of site location.

One of the goals of mankind today should be to offer good and reliable Internet access to everyone, in ispite of their location .

Proposal:

 One of the amazing things of satellite links, it’s their capability to reach virtually anywhere in the globe. I’ve had the chance to participate in satellite port installations in very remote places such as boats at sea or in remote rural or jungle sites where there isn't even cell phone signal. In turn I have seen all kinds of solutions deployed on these links: ATM (Automatic Teller Machines), PoS (Point of Sales), corporate private link and of course: Internet Access.

 During the last years I have been deeply involved with IPv6. I am a firm believer in the “Internet of things” concept, where most things need and will be connected to Internet .

  Unfortunately, for various reasons, the conventional thinking is that  Internet connections are suitable only for  home and office applications in urban sites. Even though  this is partly true, we cannot forget the great masses of people (and things) in non-urban areas, remarkably greater in developing countries. In the end, this fact becomes very negative. Millions of people are being left behind when the advantages of Internet access is taken away from them. i.e.: access to e-learning, e-nursering, telemedicine, research, cloud computing, online consultations and many other great benefits provided.

 Though fiber links, hybrid fiber-coax and very high-speed Wireless links are growing in all countries, there are places where these technologies will never be seen or will be missing for several decades. The solution I see coming, one we should not miss, is the pairing of the new Internet protocol (IPv6) and satellite communications. Of course Satellite links exist everywhere and IPv6 is coming forward, what propose is to keep those technologies together.

It is my point of view that this combination is the only one that really combines a long-term feasibility. And is currently achievable! This is the right way to connect everyone in the globe and also support the emerging new protocol and many Internet-based services that already exist and undoubtedly will be growing up at least during the next few years.

Unfortunately satellite technology providers have been among the last to offer IPv6 based solutions. At present, if you google something like: “IPv6  satellite hubs” you won’t get an easy link to click on, and then, if you hit on the results, you won't find  major Satellite vendors that specifically support IPv6 Hubs. As far as I know, last year there was only one Satellite Hub manufacturer that added IPv6 support to its solution. Saying that, we have seen a change, though small, by one  supplier.  There looks to be already products (very few) on the market with native -IPv6- implementations. My belief is that with some support from the community, and probably from some organization and collaboration we can do this combination a “must to have” among satellite hubs suppliers. We think that if the satellite industry  keeps growing without IPv6, it will be worse for it in the long term. Our assumption is based upon what IPv6 has to offer and what  the lack of it might do to remote locations: 1) missing IPv6 in satellite technology in those locations will hurt IPv6 deployment, 2) Those places won’t enjoy some benefits offered by IPv6.

 Finally, I would like to mention that traditional problems found in satellite links such as: 1) round trip delay and 2) costs; are being solved with new technologies. Also there are some new initiatives that will boost even more this situation.

Conclusion:

 The combination of satellite links and IPv6 is the right way to provide Internet access in very remote places in order to prepare for the current and the future of Internet-based services.

IPv6 - Humor - Comics (English version)

Advertising IPv6 Routes Between IPv4 BGP Peers (Cisco)

Situation:
  I want to advertise IPv6 networks / prefixes over IPv4 eBGP session
History:
  Although not common, this case may occur in some situations. 
  For example, in this moment, I have a Cisco router with IPv6 support (routing) but do not support BGP IPv6 neighbors
Error (just in case):
  (Probably you are receiving the message below)     :)

*Mar  1 02:05:00.663: BGP: 1.1.1.1 Advertised Nexthop ::FFFF:1.1.1.1: Non-local or Nexthop and peer Not on same interface
*Mar  1 02:05:00.663: BGP(1): 1.1.1.1 rcv UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, originator 0.0.0.0, path 1, community , extended community
*Mar  1 02:05:00.667: BGP(1): 1.1.1.1 rcv UPDATE about 2001:db8::/32 -- DENIED due to:
*Mar  1 02:05:00.667: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar  1 02:05:00.771: BGP(0): 1.1.1.1 computing updates, afi 0, neighbor version 0, table version 25, starting at 0.0.0.0

 
Solution:
  Fortunately BGP support carrying routing information for different protocols (ie. IPv6). Therefore it is possible to exchange prefixes IPv6 over eBGP IPv4 sessions.
Configuration:
  In this basic scenario with R1 <--> R2 connected back-to-back the configuration is as follows (the prefix announced by R1 is learned by R2).

R1:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::1/64
 ipv6 enable
!
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 1.1.1.2 remote-as 2
 neighbor 1.1.1.2 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.2 activate
 network 2001:db8::/32
 no synchronization
 redistribute static
 exit-address-family
!
ipv6 route 2001:db8::/32 Null0

R2:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::2/64
 ipv6 enable
!
router bgp 2
 no synchronization
 bgp router-id 1.1.1.2
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.1 activate
 neighbor 1.1.1.1 route-map IPv6-NextHop in
 exit-address-family
!
route-map IPv6-NextHop permit 10
 set ipv6 next-hop 2001:db8::1
!
"The trick":
  * The session must be eBGP multihop, if not, R2 will not learn the prefix (the same error as seen above). I admit I do not get 100% why it happens however after readings some documents it looks like the router complains that the next-hop IP address and the way it was configured are in different subnet (make sense, one is IPv6 and IPv4 another!).
  * In R2 (who receive the prefix) there must be a route-map applied (in) forcing the next-hop IPv6 address of R1
After applying ebgp-multihop (everything works):
* Mar 1 02:01:42.539: BGP (1): 1.1.1.1 rcvd UPDATE w / attr: nexthop :: FFFF: 1.1.1.1, origin i, metric 0, path 1* Mar 1 02:01:42.539: BGP (1): 1.1.1.1 rcvd 2800:26 :: / 32* Mar 1 02:01:42.543: BGP (0): Check route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table* Mar 1 02:01:42.543: BGP (1): Check for installing route 2001: db8 :: / 32 -> 2001: db8 :: 1 (::) to main IPv6 tableMore information:- https://supportforums.cisco.com/docs/DOC-21110- http://ieoc.com/forums/p/15154/130174.aspx- http://ieoc.com/forums/p/15154/130174.aspx

I hope it's useful!

IPv6 crosswords puzzle

http://goo.gl/lVuv6

I hope you enjoy it :)