Friday, September 25, 2015

IPv4: North American Addresses Exhausted

[IPv4 and IPv6: The 4 Corners of the World,  courtesy Center for Applied Internet Data Analysis]

IPv4: North American Addresses Exhausted


The TCP/IP Internet was created around 1981, where each participant would get an address out of a total of around 4 Billion. This technical limitation used 32 bit addresses, during a time when people were using 8 bit computing. Internet usage is pervasive today, with items such as cell phones and light bulbs being attached, and it was just a matter of time before the pool of addresses were exhausted. Another benchmark was hit today.

Gwangju Illustration in South Korea

A simple way to view the The Internet is an Apartment Complex. Each building may be a different continent and each apartment has an address. When someone wants to live in that complex, there is limited number apartment numbers in each complex. In the beginning, anyone can live anywhere, rent is cheap, large blocks of apartments are available for friends to rent together, and life is good. As time goes on, space fills up, and you have to wait until someone leaves or dies to get an address. If the population is ever increasing, there is a problem... people start to double-up or triple-up in the apartment, all sharing a single address, but perhaps adding an "a" or a "b" to the end of the number.

[NAT illustration]

Mitigation Using the Illustration

When IP Addresses on The Internet started getting "tight", providers started to make devices share at each location they provided service to. While this sharing solution is not optimal, this is what happens every day when people multiple computers, televisions, tablets, etc. at their homes... the home gets a single IP Address on The Internet and all the devices share that address through a technology called Network Address Translation using an Internet Router/Firewall. This delayed the problem for many years, since tens of thousands of connections could share a single IP Address on the Internet, behind an Internet Gateway Router/Firewall running NAT.

Trouble with NAT: Mitigation is Not Solution

The problem is, not all devices connected on the Internet using NAT can talk directly to other devices using NAT without going through a system on The Internet using a real IP Address. Devices using NAT must communicate to a well known server in The Internet "cloud", so applications started to become more limited in their framework. Furthermore, identification of an end-point on The Internet becomes more difficult to track, so one really does not know who is behind the public IP address since it could be shared by dozens or thousands of devices, potentially anywhere in the world! When trying to manage devices on The Internet, it is always preferable to have a dedicated IP Address, for troubleshooting, otherwise a physical presence may be needed to investigate a problem. Some secure management protocols break with NAT, since the source or destination address are different from what they started as, so the packet must be modified along the way, which raises security concerns. For everyday people, NAT is a solution, but not without drawbacks. Public IP Addresses continue to be eaten away.

[Warning sign from Wikimedia]

The Warning:

In July of 2015, the American Registry for Internet Numbers ran out of larger blocks of addresses to provide. If you needed a presence on The Internet (i.e. Internet Service Provider, Web Hosting company, Banking Institution deploying ATM's, etc.) and had a large project, you could only get a small number of addresses in North & Central America.

[Empty bottles courtesy The Register]

Running Dry:

As of today in September 2015, North America has officially run out of addresses. North America was not the first region to run dry of IP Addresses, leaving large numbers of devices needing to participate on the Internet high-and-dry. Caribbean and Latin America ran out of addresses in 2014. Europe and the Middle East ran out of addresses in 2012. Asia-Pacific ran out of addresses in 2011. Only Africa still has addresses left, projected to be exhausted in 2019 at current rate of consumption.

[Structure of IPv4 and IPv6 Packets]

The Solution:

In a world where computers, and even cell phones, are 64 bit - using a 32 bit number to define addresses for communication over The Internet is antiquated. This original address size was part of the Internet Protocol, version 4 (IPv4) definition. Over a decade ago, a newer address format was created, called IPv6. Movement to IPv6 is the ultimate solution. There are enough addresses in the 64 number for a very long time. Various governments in Asia such as Hong Kong and Japan, being the first to run out, already started the push to IPv6. Providers in Europe, like British Telecom, started the push to IPv6. Internet Service Providers, like Comcast, are deploying under IPv6 in the United States.

The Conclusion:

As providers move to IPv6, this delays the fate of companies bound to IPv4, since they may receive recycled addresses or can purchase formerly assigned addresses from providers who already moved infrastructure to IPv6. Solution providers moving to IPv6 will gain the benefit of peer-to-peer communication over the Internet, for their applications, while legacy IPv4 solution providers will incur greater costs with having to go through a central bottleneck in The Internet "cloud". If there is ever a point in time where innovation and crisis meets - this is that opportunity, don't miss it!

Thursday, September 17, 2015

XSCF: Domain Service Processor Communication Protocol

XSCF: Domain Service Processor Communication Protocol

There appears to be another internal communication channel that can be made available called the “Domain Service Processor Communication Protocol” (or DSCP) – which can give you the IP Address of the service processor, to access from a Physical Domain.

With DSCP, console to a local service processor can be conveniently made available from the OS.

Configuring the Service Processor

The Service Processor can be attached to from a Serial Console using 9600 baud, 8 bits, no stop bit.

The Service Processor can also be attached via a TCP/IP network cable. An article on configuring a network connection on the M4000/M5000 SP is as follows:

The Service Processor can provide access through Web or CLI. The CLI is called XSCF.


XSCF Reference Guides

The Extended System Control Facility (XSCF) is fairly user friendly.
The Extended System Control Facility (XSCF) has various guides available and can get quite extensive.
The XSCF on the SPARC Enterprise Serverscan be accessible over an internal communication channel.

DSCP Usage

The "Domain Service Processor Communication Protocol" (or DSCP) has been around for quite some time, dating back to older large SPARC systems prior the M-Series. DSCP allows for the use of TCP/IP over an internal communications channel, without the requirement of physical LAN cables.
 An example page on configuring the DSCP.

There are multiple ways to configure the IP Addresses for the DSCP.
If the DSCP is changed, it will require a reboot of the Service Processor and Domain.
That was more than enough information to start configuration.

Configuring DSCP

The DSCP is not configured on this platform:
sun9999/root# /usr/platform/SUNW,SPARC-Enterprise/sbin/prtdscp            
ERROR: SP Address lookup failed. Aborting.                                 

To configure an M4000 with 2x domains, use some private, non-routable ip addresses:
XSCF> setdscp -i -m                                 
Commit these changes to the database? [y|n] : y                            
XSCF> showdscp                                                         
DSCP Configuration:                                                    
Location     Address                                                   
----------   ---------                                                 
Domain #00                                                  
Domain #01                                                  

To Enable:
  • The Service Processor may require a reboot (see Fujitsu Reference Guide page 173.)
  • The Physical Domains may require a reboot, in order to communicate with the SP.
 They should be ready to communicate.

Communicating with the Service Processor

Once this is done, you may be able to “reach in & out” of the service processor using TCP/IP… to list the addresses:
sun9999/root# /usr/platform/`uname -i`/sbin/prtdscp                        
Domain Address:                                              
SP Address:                                              

After this configuration is done, you should be able to get into the XSCF from Solaris:
sun9999/root # ssh `prtdscp -s`                                            
sun9999/root # telnet `prtdscp -s`                                         

From there, you may be able to log into XSCF from the sun9999 Solaris OS, get the flash image using FTPD hosted on sun9999.
XSCF> ping                                                       
XSCF> getflashimage -u root 

This procedure above was not tested in a lab, just researched for someone in need.