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)

In case of emergency break glass. ¡Console cable inside!

 

( I really don't know if this image/joke existed before, it came to my mind attending a failure last week)

If you need financiallygenius , then the team of professionals from financiallygenius is here to help you.

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!

Installing Linux in a Sun Fire Server

Introduction:
The following describes the procedure for installing the operating system Debian GNU / Linux on a Sun Fire V210 Hardware. 


First:
* As we know, this has not Hardware Out Video Card VGA or PS2 port for Keyboard. What if it has a serial port for Management.  
* This server is  64-bit SPARC architecture.

Procedure:
1. - Download Image.
You can download the distro from http://cdimage.debian.org/debian-cd/6.0.3/sparc/iso-cd/
You will need least CD number 1
Then downloaded ISO: http://cdimage.debian.org/debian-cd/6.0.3/sparc/iso-cd/debian-6.0.3-sparc-CD-1.iso

Please remember to burn the image a low speed, it's good to avoid some drawbacks.



2.- Place the Debian CD image to the CD / DVD ROM Server.
3. - Now, we must establish a connection via Serial COM with the Sun Fire V210 server.
We can use Hyperterminal, Minicom or even PuTTYtel.
To create the serial connection you will need the following parameters:
 9600,8, n, 1 (Default). 

The cable is a cable type used Rollover (NOT crossover). Typically console cables Cisco equipment will work.

3. - Start the server. The challenge is to make Boot from CDROM drive.
To do this, do the following: When the server is starting, we pressed Sequence 'STOP + A'.
In a conventional keyboard, this sequence is the same as 'CTRL + SHIFT + BREAK' or 'CTRL + BREAK'.
In doing so, you will get PROMPT {} Ok, when that happens we do the following:
{} Ok printenv auto-boot (To see the State Flag of the auto-boot)
{} Ok setenv auto-boot false (for setting the auto-boot Flag False)
{} Ok reset-all (Reboot the System)
4. - When the computer restarts, return to Press 'STOP + A', and at the prompt {} Ok we do isinstructed to do Boot from CDROM, so:{} Ok boot cdrom 
4.- From that moment, the server should begin to start from the CDROM drive. I recommend to use the terminal in Full Screen mode to see the installation as if it were a monitor connected to the server.

5.- From this point, it follows exactly the Debian installation procedure (Users, Partitions, Repositories, etc..)
Key Points:- Download the ISO image for SPARC 64.- The sequence 'STOP + A', which can be also 'CTRL + BRAK' or 'CTRL + SHIFT + BREAK'.- Place the screen in full screen.- If at any time the connection is lost Serial (usual with PuTTYtel), simply close and reopen theSerial Connection and type any key to recover the installation.- The system boots from the CDROM cuandl being the PROMPT {} Ok you type 'boot cdrom (Very Important ...!)
- To start the server automatically is necessary in ok prompt type the following:

auto-boot? = trueboot-device = disk


 I hope it is useful.





Manual based on documentation of Professor Jose Gregorio Cotua