Blog BN′B

BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks BN'B

The BASIL Networks Public Blog contains information on Product Designs, New Technologies. Manufacturing, Technology Law, Trade Secretes & IP, Cyber Security, LAN Security, Product Development Security

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-7

saltuzzo | 23 November, 2017 06:56

Part 7: IPv4, IPv6, Protocols - Network, Transport & Application: Continued
The Ethernet Protocol(s) CRC-32 and Checksums

Design is a way of life, a point of view.  It involves the whole complex of visual communications: talent, creative ability, manual skill, and technical knowledge.  Aesthetics and economics, technology and psychology are intrinsically related to the process. - Paul Rand

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 IPv4 & IPv6 Protocols - Network, Transport & Application (January 10, 2017)
Part 5 IPv4 & IPv6 Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6 IPv4 & IPv6 Protocols - Network, Transport & Application Continued - The Ethernet Protocol(s) (Sept 21, 2017)

Quick review to set the atmosphere for Part 7
From the previous Internet of Things Part-1 through Part- 6:

  • All serial hardware protocols have to have some methodology to identify a starting point for the data transfer and the end of the data transfer, as well as when each bit is valid to be sensed.
  • We presented an overview of the list of protocols that IPv4 and IPv6 are able to handle as well as an overview of the list of protocols we wish to initially implement into our IoT Core Platform.

We presented the first part of the Ethernet Protocol hardware characteristics, the software frame structure and how it identifies devices on its network.
The Ethernet Physical Layer incorporates the following capabilities and features:

  • a differential twisted pair configuration for Transmit and Receive lines.
  • cable length is determined by the hardware, general Cat[5][6][7] cables are at least 100 Meters for 1Gbps and lower;  30 meters above 1Gbps
  • a variable length protocol - the payload varies from 46 bytes minimum to 1500 bytes maximum with an added eight bytres (802.2, 803.1Q) for inter layer links if incorporated.
  • an internally hardware controlled asynchronous autonegotiation protocol - uses 8 bytes to determine configuration and 12 idle bytes to end data transfer.
  • auto-configuration to run Full or Half duplex  for the 10/100 BASE-T,  1Gbps BASE-T and above run in full duplex only.
  • Ethernet switches internally maintain the devices IP and MAC address of devices connected to each port.
  • a mechanism through Ethernet switches allowing device to device communication without router intervention.
  • MAC addresses must be unique to the connected LAN devices.
  • Manufacturers must be assigned a block of MAC addresses along with a manufacturer ID.
  • The Ethernet Controller requires eight octets, a  block of 31 sets of state changes 1's and 0's to configure the controller for the start of the data
  • The Ethernet Controller requires a block 12 idle states to identify the end of data transfer or have a specified length in octets 20, 21 of  the frame.
  • Protocols have some way of checking or insuring the integrity of the data being transferred - many protocols use a Checksum or Cyclic Redundancy Check (CRC) -16/ 32 etc. bit algorithms.
  • Protocol and Headers are all not the same in the way the CRC's are implemented.

What we want to cover in Part 7:

The Checksum Algotiyhms and the Ethernet Protocol Cyclic Redundancy Check (CRC-32) 
In this part of the series we will present the error-detection section of the protocols for the Core IoT Platform, the checksum and the Ethernet protocol CRC-32.  We will start off with some ground floor history of error-detection in serial data streams and proceed to the  various algorithms that have been develop for the Internet.  We will then present an introduction with a bit of history of the embedded processor, microcontroller and CPU marketplace.  To close this part we will present an overview of the Core IoT Platform requirements in order to create an IoT Platform functional block diagram. The outline is listed below.

Enjoy the series.

Lets Get Started: A "BIT" of CRC and Checksum History
Serial data transfer from its conception to present day has the task of insuring that the data block of bits being transported does not contain any changed bits during transfer.  Before the Internet serial communications were part of the telecommunications and information theory, coding theory, cryptography and others.  What the innovators looked at was how to detect bit reversals in a block of bits and ignore the actual format of the data being transferred.  All that was of interested was that there were no bad bits in the block of bits period.  Well to look at this reality we have to look at how many bit reversals exists in the source block of bits and calculate a methodology to test for any reversals.  If there are no reversals then it is assumed that the block of bits was transferred correctly with no errors.  This simple explanation has created a "bit" of confusion in the serial digital world and still exists today.  Ok, the research of bit reversals leads us into the theory of how several checksum methodology evolved to and how to place them in the block of data bits for the best performance.  Checksum algorithms vary in the world of processors and programming, there are a set of simplified checksums for embedded processors that handle smaller data transfer sizes to the Internet that handle gigabits of data continually.

The object of the theory is to detect errors in transmission by using some sort of error detection code sequence which was introduce back in the 1940's by Richard W. Hamming who modernized the development of error-correcting codes.  This was fast evolving by the contribution of other theorists and ended up with the name Hamming Distance and so we have the introduction to checksums and CRC by way of Error-Detecting Codes and Correction incorporating Hamming Distance theory.

Hamming Distance:
The Hamming Distance (HD)  is defined as the number of transitions required to make two strings of identical length the same.  Hamming Distance is an interesting theory when applied to comparing a block of bits as we will see shortly.  It is also an interesting application when applied to cryptography and ciphers.  Hamming Distance is a starting point for cracking a cipher based on language, region, and bit changes within blocks, there are several other brute force methods as well which will be discussed in another blog on cryptography in the future.  OK, so the question, what does Hamming Distance have to do Checksums and CRCs?  The larger the Hamming Distance number means the more bit reversals within the block of bits being tested and the reference block of bits, the more difficult it is to be exact that a bit error will be detected.    Lets take both Checksum and CRC separately and look at the methodology and how they would detect bit errors.

There are many documents published detailing several different methodologies to test a block of bits, in fact so many that some sort of standard had to be set for the Internet in order to insure some type of data transfer integrity where all system use the same methodology at both ends to insure consistency throughout the networks.  As we stated in previous parts of this series, "as long as you follow the protocols in place the data will be routed source to destination however, there is no guarantee that the data will not contain bit errors "and" that is the main task of the CRC and Checksum algorithms.  The user data extraction is up to the application to encode/decode the users data which also should contain some sort or data integrity checking process as well.  So with that said we will look at the protocols being presented which are Ethernet, IP, TCP, and UDP and the checking methodologies used to insure data transfer integrity.   There is an intense amount of research information on serial data bit testing and grouping of bits into blocks of various sizes attempting to create the best process of identifying a single bit error in a large block of data during transfer.  We will give some references at the end of this part for reference, one could make a career in error-detecting-codes, that is not the intent here, just an overview with an understanding to implement the algorithms for our IoT Core Platform development.  There are so many web pages that give the source code in several languages for the Hamming distance function eliminating the need to present it here.

We often see in the protocol header used in the Internet fields labeled  "Checksum", Frame Check Sequence (FCS) , CRC and others, these fields may be a Checksum or CRC or some other error checking methodology unique to the protocol. To clear this up we will look at the checksum functions and the Cyclic Redundancy Check (CRC) algorithm which are the main functions used for many of the protocols, specifically for the initial IoT Core Platform.  We will return to the Checksums and CRC later in the series when we address the programming of selected protocols and the OSI model.

Hamming Distance And The Checksum:
Here we are now 20 years later into the 70's and still wondering how to best incorporate the error detecting and error correction codes for large amounts of data transfers.  Well lets do a slow walk first to see how this bit reversal and error detection evolved.  The Hamming Distance theory set the sites of looking at the reduction of bit reversals in a segmented block of bits for transferring data insuring that if a transfer error or bit reversal happened it would be detected.   This lead to the simplest proof of the Hamming Distance Theorem when it was implemented into a ASCII hex file data format representing bytes of data.  This simple checksum algorithm was introduced by Motorola and based on the 6800 microprocessor series and given the names SRECORD, SREC, S19, S28, S37 file format which was commonly used to program the flash memory, the loading format was not very fast but very efficient at the time.  Intel Corporation® reviewed and revised the file format for use on the 8008 CPU in the early 70's and eventually created a new specification for the Intel processor line in the late 80's and labeled it the IntelHex File Jan 6, 1988 for the entire x86 line of processors.  OK enough of ancient history, although roots are important, even though they are routinely ignored the tree would not have grown without them.

The IntelHex file format checksum is the interesting section of the IntelHex File format that we want to cover here which is defined as the sum of all the data bytes in the single line as shown in Figure 7.0 below.  The line of code has a maximum length of  [Start Code(S) + Byte Count + Address +  Record Type + Data ] bytes all represented in ASCII Hex format.  Each eight bit byte is represented by two ASCII hex characters (0-9-A-F)  for a maximum ASCII hex character line length of [1*2 + 2*2 +  1*2 + 256*2 ] =  1032 ASCII hex characters + 1*2  characters for the checksum which is attached to the line after calculation.

The checksum calculation is the two's compliment of the Least Significant Byte of the summation of ASCII Character bytes in the line less the Start Character, ASCII colon ":".  So how is this effective?  Lets look at Figure 7.1 The Hex Number Notation and the actual data transitions of the hex data 0-9, A-F  in binary format, they are 0x30 - 0x39 and 0x41-0x46 respectfully to binary string values are 00110000 - 00111001  and  01000001 - 01000110.  So as we see the number of transitions to make any two binary hex digit strings to be the same is always less than 5 transitions.  This is important for checksums since the lower HD number the better chance of catching a bit error in a sequence.  The upper case A-F  is used since bits 5, 6, & 7 never change leaving only 5 bits to test. Bit 4 gives a minimum HD of 1 and the detection of  a bit reversal would only require the checksums to be different.  This is the reason that the simple IntelHex File checksum is effective.  This checksum algorithm would have a greater opportunity to miss the detection of a bit reversal if the entire byte of 255 reversals were allowed.

The IntelHex File Format for transferring data is one of the "least efficient" methodologies and would totally burden the Internet, however for loading an embedded processor program memory, FPGA's, CPLD's EEPROM etc. it is efficient and accurate which is why several embedded processor manufacturers incorporated it into their Integrated Development Environment (IDE) tool and still widely used today.  Since the IntelHex File Format is only applied for single text line of characters with data blocks of 256 bytes [256x2 hex characters] or less makes this algorithm not applicable for Internet data transfer checking function that require large amounts of data transfers.

IntelHexFileFormat
Figure 7.0  Intel Hex File Format Example

ASCII_HEX_BinarySrting.jpg
Figure 7.1  Hex Numbers 0-9 A-F in Binary Notation

Taking into to account what we are looking for is actual bit reversals from the transfer of data from source to destination through a medium.  So if we look at the data and ask the following questions while visualizing the data blocks shown in Figure 7.2.

  • What would be the optimized block size for the checksum?
  • What is the reliability of detecting a single bit reversal anywhere in the block of bits?
  • What is the probability of detecting several bit reversals in the block of data?
  • How many unique bit reversals would have to convolve to give the same source checksum results?
  • What is the probability of several bit reversals that would convolve to give the same source checksum results?

Checksum_Blocks
Figure 7.2  Hex Numbers 0-9 A-F  Sum of Blocks Calculated Checksum

For this example we are only using the ASCII Hex byte for simplicity since the resultant G(x) size for the sum would be less than 16 bits and the highest bit change would be bit five would be 64 x 1032 = 66,048 which would require 17 bits sum register for G(x).  Looking at the bit patterns in Figure 7.1 and the blocks in 7.2, in order to get the same checksum from bit reversals two consecutive blocks would have to have a specific bit reversal that would subtract from one and add to the other to give the same sum.  The probability of this happening is very small due to the uniqueness of the ASCII Hex bit patterns.  The probability of detecting one to several bit reversals is very good.  This is why the ASCII Hex file format has a high reliability.  If all eight bits were to be used this would reduce the reliability and be difficult to handle if the total number of blocks were to increase.   This is the basics to understanding bit reversals and the front door of error-detecting, error-correcting code sequences.

Moving forward, to the late 70's an individual from Lawrence Livermore Labs credited for creating a flexible checksum algorithm that incorporates a variable block size and was given the name the Fletcher Checksum after its creator John G. Fletcher (1934-2012).  This added more credibility to the error-detection process and is used throughout the Internet today.  However, keep in mind that all checksum algorithms that use the sum algorithm process have their limitations since it is just a sum and XOR of bits that give a result on a block of bits.  Adding two byte/word bit strings is a simple non-cpu taxing process and is the fastest algorithm for obtaining a sum of a block of bits for a simple checksum algorithm however, as stated it does have its limitations.

The Fletcher Checksum implemented a Checksum Size to the process which allowed variations for different applications and improved performance. If the groups are sized properly depending on the Hamming Distance the probably of missing the detection of a bit reversal is reduced to a very usable state for transferring large amounts of data as well as loading embedded system memory that would be apparent over the Internet, however it is still questionable today of its performance with present Gigabit network speeds.  The Quality of Service (QoS) of the Internet is quite high and if the physical layer is properly installed the transfer errors are very low;.in a gigabit network even if the data resends a few packets it would not be realized over time.

CRC Versus Checksum:

Checksum Overview:
A Checksum is a simpler runtime calculation of a group of bits to determine if any errors occurred during a data transfer process.  There are several checksum functions or algorithms depending on the design goals and would usually work on small datum sizes.  Checksum algorithms are Parity byte or Parity word,  Modular Sum,  Position-Dependent.  Before the innovation of disk drives serial data transfer existed way back and used the simple audio cassette player - the Commodore Vic20 C2N-B Datasette.  The Datasette was so reliable that they were widely used in Europe while the USA was moving to the disk drive.  The first digital error checking was writing the data twice and checking it twice, not much for efficiency however very accurate.   This progressed to a faster method for transferring digital data that incorporated the simple checksum methodology.  The original simple checksum was created by Motorola for the 6800 and progressed to the Intel Corporation IntelHex File Format as stated earlier.  

Cyclic Redundancy Check CRC Overview:
The CRC (Cyclic Redundancy Check) algorithm was initially created in 1961 by W. Wesley Peterson.   The CRC size used in the Ethernet physical layer protocol is 32 bits (CRC-32) and was derived from the work of several researchers and was eventually published in 1975.  The CRC was created to work on blocks of binary bits, hence the CRC-dd where dd is the size of the binary block.  The CRC is an integer algorithm, no fractions or remainders, which implies that it is not exact and has "bit" limitations. In fact there has been a lot of research into the CRC algorithm(s) to select the optimized polynomial size and bit blocks for the Internet as well as other serial protocols.  The tradeoff for using a CRC or Checksum algorithm is that the data it is applied to is not changed in any way as with encryption and other algorithms that change and add data to the original data and increase or decrease the length.  Before we get into irregularities of the CRC lets focus on the protocols we want to present, the Ethernet Protocol which uses a CRC-32.

Hamming Distance, Polynomials And The CRC
Hamming Distance and the CRC polynomial methodology has been around for many years prior to the Internet that DARPA was developing in the 70's.  Today after all the research and papers published the conclusion is that there is no single CRC polynomial "silver bullet" that will yield the same performance for all the applications.  This has created some challenges for the Internet Standards Group to define a error-detection code standard for Internet traffic as well as create some confusion for hardware and software developers.   There still are different CRC size algorithms being used today for specific applications; it is important to keep in mind as we present this series that CRC algorithms are generally tailored for the best performance for the application.  Several reference links to CRC papers on various Hamming Distances and CRC sizes versus performance characteristics will be at the end of this part of the series.  We will revisit Hamming Distance, CRC, Checksums and other algorithms along with some core applications when we present the security and encryption sections of this series.  The paper presented at the International Conference on Dependable Systems and Networks covers the issue of CRC polynomials with data.   We will return to these algorithms when we address the protocol software implementation.

Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks 2004 

Philip Koopman
ECE Department & ICES
Carnegie Mellon University
Pittsburgh, PA, USA
koopman@cmu.edu

Tridib Chakravarty
Pittsburgh, PA, USA
tridib@alumni.carnegiemellon.edu

Hamming Distance, CRC, Checksum Summary:
Ok, to even attempt to put in ones own words the vast amount of research and experimental data performed over the years on the checksum vs CRC would be an exercise in futility.  So instead lets acknowledge the brilliant minds that already performed these tasks with precision.  Review at your leisure to understand the unique variations of the two algorithms and keep in mind that there are issues with many of the error-detection coding used on the Internet.

Performance of Checksums and CRCs over Real Data (1998)
Craig Partridge (Bolt Beranek and Newman, Inc),
Jim Hughes (Network Systems Corporation),
and Jonathan Stone (Stanford University)

Looking at systems in mathematics and definitions, multiplication is group addition and division is group subtraction; the basics of the checksum is group addition, we see that both CRC polynomial evaluation and checksum have similar properties.  The uniqueness of the CRC is that the polynomial allows a combination of groups because of the division and has a greater probability of detecting a bit reversal because of the Hamming Distance.  The conclusion is that error-detection for bit reversals during transmission will remain a challenging topic for one to create a fool proof methodology.  The interesting part of all this is the ability to detail the limitations of the algorithms and still be able to implement them and generally rely on their functionality as we have for the past 50 years and will continue until a better methodology in created.  We will be implementing various security protocols and policies during once the hardware has been defined for the Core IoT Platform.  This covers the initial presentation of the Internet IPv4 and IPv6 in general and gives us enough details to select the hardware platform. We will be implementing the Checksum and CRC in a software module for the first time through development.  Hardware implementation of CRC algorithms will be addressed after the initial Core IoT Platform has been through a POD (Proof of Design).

Introduction to the Embedded Processor and CPU Marketplace:

A Brief History of the Embedded and CPU Major Players
The $64,535 question of the day, which one should we pick?  Lets backup for a moment to look at the Embedded Processor and CPU Chip Marketplace and the timeline of how it evolved.  Since this marketplace is huge we will only cover some of the Mergers & Acquisitions of the major players in the marketplace to get a glimpse of the arena we are entering.  You may easily search the various manufacturers to see the transitions if you want to research this further.  OK, the major players back in time were Motorola®, Intel®, Cyrix®, AMD®, SMCC®, Microchip® and Texac Instruments®.

  • Motorola®  processor division dominated the embedded and automotive embedded market (68x00 Processors) for many years then decided to diverse its embedded division to become Freescale Semiconductor®.
  • Intel® entered the embedded market after 1986 when they moved the 80x86 CPU line to the newly formed embedded division, from that point on after every silicon rollover of older processors enter the Intel embedded arena.
  • AMD® aquired the x86 instruction set perpectual license by acquiring National Semiconductor® and Cyrix®, the creator of the Intel Math Co-Processor chip.
  • Microchip® acquired SMSC® (Standard MicroSystems Corporation)  in 2012 and Atmel® in 2016.  Microchip markets the MIPS32/64®, ARM® Cortex™ processor lines..
  • NXP® acquired Freescale Semiconductor the original HC68000 embedded processor line.
  • Texac Instruments® - Acquired Burr Brown in 2000,  acquired National Semiconductor in 2011, National Semiconductors cross license of the x86 instruction set for the Cirrus Processor.

There are several other players that cross license cores and put their own name on them which we did not mention here for simplicity.  All of the above companies and several other younger players incorporate the ARM Cortex line of processors, since ARM allows the cross licensing of  the processor technology.  This allows each of these manufacturers to incorporate the ARM processor technology and incorporate their own unique interfaces and software development environment.  ARM also distributes its own development software as well as training for the processor line. OK, that is a brief history of the embedded processor marketplace from 1971 to 2017 that shows nothing is as stable as we would like it to be when developing hardware.  For the selection process we have to decide on a 32 or 64 bit processor and which manufacturer will be manufacturing this processor for several years. Researching embedded processors on the Internet we see that there are many available, however when we review the Last-Time-Buy (LTB) we see that many are being discontinued by the end of 2018/2019.  That means that we would have to redesign the platform before we even get it on the market for a year.  Silicon rollover is one of the major concerns in the hardware development process.  If you are in the market for the long term you have to make long term decisions to insure cost effectiveness.  This is usually overlooked during the startup stages since the main objective is to get the product to market first and create the market need and identity.

The Processors Dilemma:
Embedded Processors vs CPUs vs Micro-Controllers vs System on a Chip (SoC)
There are many players in the Embedded Processor Units (EPU),  System on a Chip (SoC) and  Micro-Processor Controllers (MPC) market to choose from on a global level and only a few at most in the Central Processor Unit (CPU) market, it is acronym-alphabet soup city.  The real dilemma arises with Silicon rollover, discontinued parts, revisions that are not Plug'N'Play compatible which create a headache for the supply chain industry and a nightmare for the design engineer.  To add insult to injury manufacturers like any other business look at the bottom line and fail or just plain neglect to let the designer know when the Last-Time-Buy (LTB) date is and generally hide it from their roadmap's.  Forcing a Life-Time-Buy for any product is a very serious concern, not only for the expense for the LTB but the expense and resources required to redesign the product.  So how do we handle this conundrum? Answer: pick a stable processor, if there is one!  Manufactures of embedded components and tools are different from the standard commercial and consumer products.  Consumer products are designed to be replaced at the earliest tolerable life cycle, commercial products look at about two to three years or shortly after the instream revenue falls below the expected margin usually peaks out by 2 years.

Going back in time, the original Intel 80486 back in 1989 introduced the first processor incorporating the tightly woven pipeline architecture and remained in the embedded market for over 15 years before Intel officially stopped manufacturing the chip.  However, there are still a couple of manufacturers that still produce chip with the x86 pipeline process under one of the few remaining perpetual licenses.  The ones I found on the Internet that sell the Chip and not a fully assembled single board computer are AMD® Corporation GEODE™ Series, system on a chip with graphics engine,  ZFMicro™ Corporation  ZFx86™ which is a 100MHz 486DX pipeline processor with an 80 bit FPU core with no graphics engine and 33 MHz PCI BUS and IDE drive interface under 1 watt; both ZFx86 and GEODE series are SoC's.   The Microchip MIPS32/64®  processor line is a RISC (Reduced Instruction Set Computer) M-Class processor core and as of 2017 MIPS32/64®  processors are still being used for residential gateways, routers and other Android/Linux OS based embedded systems.  MIPS origin is formally from MIPS Technologies back in the early days.  From the history MIPS processors would be the likely choice for the IoT Core Platform.  MIPS architecture is still a pipeline architecture with some added features that add up to five additional cycles to complete the fetch and execution while balancing the System Clock to the Instruction Performance.

Which Embedded Processor To Choose? 
From Part 4 it becomes apparent that we will have to use some type of processor for the IoT Core Platform to handle the communication and security functions  Also since we are looking at both conventional AES256 as well as unconventional security methodologies for future devices we will also look at separate processor for handling the security functions.  The dual processor feature allows greater flexibility for future growth and separate processors allows the data flow to be encrypted separately for the normal Internet communications.  Selecting the right processor(s) for the platform will determine the longevity and QoS of the platform.   The objective is to be able to control all the central processor functions externally.  There are many CPU's that take all the control away from the designer such as Intel, AMD and others by incorporating an OC right inside the CPU chip at Power On Test (POT) and setsup all the driver connections to the peripherals.  This only allows the user to ride on top of this and thus allowing vulnerabilities since much of this core is Intellectual Property and protected by the manufacturer and they do have that right to protect their IT just as we are.  The difference is that if we add IP to the platform on top of someone else's IP we have no guarantee that we are the only one controlling access, basic security policy 101 especially if you are going to connect to a network in any way.

Putting our top level requirement on the table for a flexible IoT Core Platform that has reasonable RAM and FLASH memory to execute the simple to the complex application does present a challenge.  There are two schools of thought when developing a platform, the first is to reduce the chip count to the smallest possible number up front and struggle with the selection of embedded peripherals that can be shared; Second, start with a stand alone processor then add the memory and peripherals selected for a proof of design then start to reduce the design for cost savings.  There are pros & cons for both approaches.  Our approach in this series is to create a functional block diagram using single blocks for each function to get a top level (40,000 foot) envision of the all the functionality we would like for the platform.  From the functional block diagram we will look at how an embedded architecture will incorporate some of the blocks and build the system platform from there.

For those who prefer running an OS like Linux or others we will keep that in mind when selecting the embedded processor system. The embedded marketplace has caused a lot of work for the Linux development team that certifies Linux OS implementations with hundreds of embedded processors if any would be available today.  Remember if we just look at the core functions we could use other technology to add functionality later as long as we maintain control over the functional components for implementing security policies.

The Embedded Processor Selection:
We are not going to select an embedded processor at this time since we have a lot more to discuss.  Embedded processors incorporate many features for handling applications which makes the selection challenging.  The selection process for this series addresses several major features for the purpose of education from the beginner to the seasoned product developer to share knowledge in developing the IoT Core platform.

  • Long life cycle availability, at least five years with roadmap's for revisions and support. Typical for the embedded markets
  • Common assembly language across 32/64 bit platforms.
  • Processor speeds of 100 MHz minimum.
  • Full control over the boot up process of the CPU, Memory & Peripherals.
  • Free or low cost  IDE (Integrated Development Environment) platform if available.
  • Software: C Compilers &  Macro Assembler, Linux, WinCE etc. OS's supported.
  • Many application examples with source code for support.
  • Libraries available to reduce software development time.
  • Evaluation demo PCB for the selected embedded processor.
  • Selection of different configurations using the same IDE platform software.
  • Large selection of physical chip packaging, LQFP, TQFP, BGA - environment reliability.

The IoT Core Platform Peripheral Requirements:

Peripheral vs. Functions
At this time we let our imagination run free a bit and pick the main peripherals and functions we would like to have in the IoT Core Platform.  Table 7.0 Core Platform Peripherals and Functions, below list out these requirements and a short description of each.  From this list a functional block diagram may be created.  When we look at the functional block diagram it looks similar to the embedded processors with a bunch of peripherals available today.  We have a few choices at this point as to how we want to create the IoT Core Platform.  Selecting just a CPU core, Interrupt Controller, a DRAM controller and FPU would put us in the SBC (Single Board Computer) arena.  Our Intent here is to get a single chip that has many of the functions in the block diagram then add the ones that will be required per application.  That keeps the chip count down to a minimum.  However it would be great to have some type of evaluation demo board that we could test software and hardware for the peripherals we will be adding pending the application.

Peripheral Type

ISP Side     IoT Core Platform Peripherals   Description

Ethernet Controller  10/100/1Gbps

The ISP front end WAN that is connected to the Global Internet RJ45

WiFi  Controller 2.4GHz / 5GHz dual band

The ISP front end WAN that is connected via WiFi - IPv4 / IPv6

 

Peripheral Type

Local Area Network (LAN / ULA  Side     IoT Core Platform Peripherals   Description

Ethernet Controller  10/100/1Gbps

The local  LAN/ULA network connections that are for hard wired peripherals RJ45 connected  to the platform LAN / ULA local network

WiFi  Controller 2.4GHz / 5GHz dual band

This is for all the Local Wireless WiFi peripherals that are connected to the platform LAN / ULA local network

 

Peripheral Type

Local Area Network (LAN / ULA  Side     IoT Core Platform  Serial Control Peripherals Single Channel   Description

SPI (Serial Peripheral Interface)  

Standard Component and control interface. These are direct connect devices that are separate from any network or wireless protocols.

I²C (Industrial and HighSpeed ) topologies

Standard Component and control interface.  These are direct connect devices that are separate from any network or wireless protocols.

CAN (1 Wire / Differential)

Standard automotive network peripherals

RS-232/422 Serial I/O

General Purpose Serial I/O devices

   

Counter-Timer(s)

This is used for event triggering of peripherals

Real Time Clock Output

This is a separate output from the system clock that is programmable to a specific interval.

Watchdog Timer - Interval Programmable

This is a separate timer for the system integrity and insures that the system is running in the sequence programmed.

 

Peripheral Type

Local Area Network (LAN / ULA  Side     IoT Core Platform  Serial Control Peripherals  Multi-Channel  Description

Bluetooth 2.4GHz

These are for all the Local Bluetooth devices connected to the platform LAN / ULA local network

USB 3.x / 2.0 

Standard USB interface with High Speed option of 480MHz USB 2.0 minimum

Parallel BUS (16/32Bit Data) / (16 Bit Address)

This is a separate data bus for parallel type peripheral connections. It allows any type of direct connection to the platform. (Optional)

Analog Inputs 16 Bit  - 8 channels analog inputs

This is for monitoring environmental and platform parameters directly (0 ± 15Vdc standard

Analog Outputs 16 Bit -  8 Channels

This is for controlling and adjusting and calibrating sensors for environmental parameters directly (0 ± 15Vdc standard

RTD Analog Signal Conditioning Front End

This is for Platinum RTD's for very accurate temperature measurements. Separate peripheral for 8 channels

Thermocouple Analog Signal Conditioning

This is for standard thermocouples standard temperature measurements. Separate peripheral for 8 channels

 

Peripheral Type

Core Processor Section     IoT Core Platform   Description

32 bit pipeline MIPS M-Class Processor

MIPS M-Class processors allow same instruction set for both 32/64 bit. 32 bit is efficient for the IoT Core Platform.

FPU  Single/Double precision

Floating Point Processor unit - Single / Double 64 bit precision

Interrupt Controller - 8/16/32 channels

Interrupt controller to generate interrupt requests to the processor selected.

DMA controller for RAM Interface

Direct Memory Access controller to allow peripherals direct access to the RAM interface.

EEPROM interface for external parameter storage

This is a separate EEPROM storage area for platform parameters only accessible through the security interface Serial/Parallel NAND to handle up to 16 GigaBytes (128Gbits)

RAM interface for external data buffering

This is a separate interface that allows the connected peripherals direct high speed access to the memory for data collection.  Static RAM up to 32 MegaBytes

 

 

Table 7.0   Core IoT Platform Peripherals and Functions


Figure 7.2   Core IoT Platform Functional Block Diagram

OK, the functional block diagram shows many peripherals attached to the main bus, it is not very difficult to create a block diagram like this considering the number of features we would like to see in the Core platform.  The two items that should stand out are the 32 bit parallel interface controller and the Custom User Interface Controller.  If we were to remove all the peripherals those two peripherals would allow us to add just about any type of peripheral that can be imagined within the boundaries of the processor.  I am not a big fan of wireless in a process control area for many reasons that we will cover when we get into the security and software development parts of the series.  This is the first block diagram presentation of the Core IoT Platform, as we continue the series we will apply any changes to the platform as required for optimization.


Reference Links for Part 7:
The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site. The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery:  http://www.networksorcery.com
The Internet Engineering task Force:  IETF - RFC references
Wikipedia  https://en.wikipedia.org/wiki/Main_Page

The high level expert links for the CRC and Checksum are listed below; there are so many Internet references to this subject that listing them would take up several pages and is not the intent of this series.

PDF The iSCSI CRC32C Digest and the Simultaneous Multiply and Divide Algorithm January 30, 2002 Luben Tuikov & Vicente Cavannay 

PDF Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks 2004  Philip Koopman,  Tridib Chakravarty

PDF Performance of Checksums and CRCs over Real Data (1998)  Craig Partridge, Jim Hughes, Jonathan Stone

TEXT Computing the Internet Checksum RFC 1071


Part 8  Preliminary Outline:

  • Embedded Processor Technology, CPU Chips Technology,  FPGA System on a Chip - How much control do we really have?
  • Boot up Initialization processes and Vulnerabilities using embedded processors and independent CPU chips
  • An introduction to support chips for processors,  NorthBridge (MCH, GMCH) /  SouthBridge support chips (ICH),  SoC Platform Controller Hub
  • Security protocols and how they play a roll in initialization.
  • Selection of the Core IoT Platform Processor(s) and peripherals.

Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-7 The Ethernet Protocol(s): Lets Sync Up- (November 23, 2017)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=12&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-7 IPv4, IPv6 Protocols, Network Transport & Applications: <i>Continued (Sept 242017)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-6

saltuzzo | 24 September, 2017 12:08

Part 6: IPv4, IPv6, Protocols - Network, Transport & Application: Continued
The Ethernet Protocol(s), Lets Sync Up

"The more extensive a man’s knowledge of what has been done, the greater will be his power of knowing what to do". -Benjamin Disraeli

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 IPv4 & IPv6 Protocols - Network, Transport & Application (January 10, 2017)
Part 5 IPv4 & IPv6 Protocols - Network, Transport & Application Continued (Aug 17, 2017)

Quick review to set the atmosphere for Part 6
From the previous Internet of Things Part-1 through Part- 5:

  • The Internet runs on protocols period.  No protocols no Internet!  The Internet is a Point to Point (P2P) topology scheme.
  • The Internet has two network layer categories - A- The Internet Network - router to router category (OSI Layers 2-5),  B- LAN Hardware Router to Physical Layer (OSI Layer 1) category.
  • The physical network Local Area Networks (LAN) may communicate with different LAN topologies using a hardware Medium Translator to convert one topology to another.
  • Local Area Networks (LAN) are run on hardware protocols and have many configurations.  The LAN headers are stripped from the Internet Network Protocols and are not part of the MTU.
  • Packet Switched Networks - The Internet uses data packets to transport information from point A to Point B.  
  • The TCP/IP Internet Suite's four layer "grouped" OSI model still incorporates the seven layers of the OSI model.  The grouping methodology incorporates protocols to easily identify the use of selective layers one through five independently that do not require an IP header or may operate device to device communications.
  • Introduced  a typical router to router and router to Physical Layer protocol formats, Table 5.2 that will provide an understanding of the Internet schemes as well as set a format for the protocol requirements for the IoT Core Platform.

What we want to cover in Part 6:  Connecting To The Ethernet Protocol

  • Separating the Internet Protocols from the Physical Layer protocols and how they interact.
  • The presentation of the Ethernet Physical Layer protocol header that define its operation.
  • The Ethernet protocol versions that exists and the headers that separate their identity.
  • Construction of the Ethernet basic protocol header for device to device communications
  • Capture real Ethernet Protocol data and display incoming and outgoing traffice over the Ethernet bus.

Lets Get Started: Some Serial Communications Basics
Hardware communications protocols are generally refereed to as a BUS Protocol like RS232, RS422, RS485, USB, are all hardware topologies used to transport data serially over a physical medium, each having their own fixed specifications.  Serial communication data hardware has been around for many years and active way back before the first computer system was placed on the market.  There are basically two types of serial communications, Asynchronous and Synchronous.

Asynchronous communication bus is where data is understood to be clocked at the same rate for devices at both ends of the bus, triggered by a detection of the first edge transition defined as the Start Bit and repeated for a defined number of bits then ended with a clock cycle defined as a Stop Bit.  The most common Asynchronous BUS is the RS232 Universal Asynchronous Receiver Transmitter - (UART).

Synchronous communication bus is a bus that sends its clock time interval on a separate wire to identify the time interval the data is valid on the data line, hence the sending of the data is set to a predetermined time interval that is synchronized by the clock interval transferred with the data.  Synchronous hardware protocols are I²C (Inter-IC ) BUS, Serial Peripheral Interface (SPI) and others that have a fixed clock wire transferred with the data wire to identify the data valid time interval.  Figure 6.0 shows the basic block format requirements for hardware protocols for serial data buses.

SerialBlockBasics
Figure 6.0  Serial BUS Basic Structure Block Diagram

The Ethernet BUS Physical Device Hardware:
The Ethernet hardware protocol bus transfers data from a unique source to a unique destination serially.  The Ethernet bus Network Interface Controller (NIC) has to configure the Data Transfer Rate (DTR), configure the Mode(Half/Full Duplex), Specify source device, Specify destination device, Detect corrupt data, resolve collisions and extract the data payload.  The collision part is easy since the Ethernet Switch handles that with only one device per  switch port, we will get to the Ethernet Switch shortly.  The Detect corrupt data issue is rare on a properly installed network however, if the data is corrupted the packet is just dropped and there is no way to know where it came from so the sender has no knowledge of it being corrupted either and just keeps sending data.  For high QoS (Quality of Service) networks there are feedback and data manipulations techniques used to insure data integrity; we will cover that in the software development part of the series.

The Ethernet Physical bus may be configured to operate in half or full duplex mode although half duplex is rarely used today. Half duplex was setup initially setup with coaxial cable mainly to avoid collisions and continued on with the introduction of the Ethernet Hub, since Ethernet Hubs are half duplex devices. The hub introduced the single port, single device concept and made it easier than running coaxial cable from device to device; the Hub has been replaced with the introduction of the Ethernet Switch.  The Ethernet switch is a more flexible device that operates in both half and full duplex mode among other unique features .that we will discuss later.

The Ethernet hardware network is the most common of the physical networks today and is used in the majority of businesses and home Internet connections and has several speeds of 10Meg bps,  100M bps,  1Gig bps and 10/25/40 Gig bps.  There are other Physical Layer protocols also in use today as we discussed in Part-5 Table 5.2, however we will focus on the Ethernet for this part of the series.  We will review the implementation process for other Physical Layer medium topologies when we address integrating different network medium topologies into the IoT Core Platform later in the series.

Moving forward, the Ethernet Physical Layer cable connections does not incorporate a physical clock line in the bus architecture which implies that  the bus in the asynchronous communications bus category.  The standard configuration today for the Ethernet bus is full duplex and the cables eight twisted pairs of the modular connector uses a differential signal twisted pair for the Transmit data and a differential signal twisted pair for the Receive data.  The remaining twisted pairs are used for various integrated features like PoE (Power over Ethernet) and other higher speed configurations.  So how does the controller configure itself to the different transmission speed ?   We will answer that question next.

The Ethernet Protocol Header(s): The Ethernet Physical Hardware Topology
OK, so if the Ethernet connector does not have a separate clock line and is a "Full Duplex" TX/RX differential pair set, how does it configure itself to the different 10/100/1Gps BASE-T etc. data speed being transported over the LAN bus?  The answer is the controller autonegotiates to the serial data stream data in the first eight octets(bytes).  We will show how this is done while we introduce the 802.3 Ethernet Header format.

The structured format of the Ethernet Physical Layer bus follows the basic serial bus format of a Preamble (Start ID) and Inter-Packet Gap (End Idle Time) format with a data payload in the middle.  The controller monitors the data transitions during the Preamble eight Octets(bytes) and if the transitions of the preamble are at stable intervals the configuration will use preamble intervals to set the controllers clock, mode etc. and be ready to receive a Start Frame Delimiter (SFD) byte eight and then begin the receiving of the data payload octets.  This configuration methodology categorizes the Ethernet bus as being an asynchronous autonegotiation bus configuration for half/full duplex mode as well as 10/100/1G BASE-T.  The Ethernet switch is an important device for this since it allows each port to be configured separately and the single port per device allows easy disconnect from the network without any loss of performance.

The details of the Preamble is a fixed pattern of alternating 1's and 0's for the first eight octets of the Ethernet header as shown in Figure 6.2a as 10101010-10101010-10101010-10101010-10101010-10101010-10101010- 10101011.   The last byte of the Preamble is the SFD (Start Frame Delimiter that ends with two 1's identifying the start of the data payload being transferred.  From this point the controller is expected to be asynchronously clocked, (destination data rate is auto-adjusted to the senders data rate) to start collecting octets from the frame.  If the controller is not configured it drops the entire frame and waits for the next frame after the Inter-Packet gap idle period of 12 octets.  The data is collected and stored starting at first octet after the SFD and ends when there is no more data after the checksum or for the maximum frame size and the bus becomes idle for 12 octets at which time the controller resets and is ready for the next header.  The 12 octet idle time is defined as no data transitions on both Transmit and Receiver pairs which signals the end of the frame.  The octet count is given as the first octet after the SFD plus the last octet of the Checksum and retained in the transfer data buffer to inform the connected API the number of octets it has to processes.

There are three unique structures for the Ethernet frame and they are shown in figures 6.1a, 6.1b and 6.1c.  The three frames have the same fields up to octet 21, then the frames in figure 6.1b and 6.1c incorporate new fields.  The field differences are the addition of the 802.2 protocol to identify pointers and inter-layer communications and is processed uniquely by the source/destination layers.  Remember back in the series the statement was made that the user data can be anything as long as the transfer point to point follow the available protocols and the user data encoder/decoder are a matched at both ends.  We will get into the inter-layer communications later in the series, for now the decoding after octet 21 is up to the Application Program Interface connected to the transfer to decode/encode the payload.  

Ethernet_Header_Frame
Figure 6.1a  802.3 Standard Ethernet Physical Protocol Header Format

EthernetFrameBlockHeader1
Figure 6.1b  802.3 + 802.2 Ethernet Physical Protocol Header Format
Source Service Access Point (SSAP)
Destination Service Access Point (DSAP)

EthernetFrameBlockHeader2
Figure 6.1c  802.3 + 802.2 + SNAP  Ethernet Physical Protocol Header Format
Source Service Access Point (SSAP)
Destination Service Access Point (DSAP)
SubNetwork Access Protocol (SNAP) Control

Figure 6.1a shows the standard Ethernet II frame commonly used for the Three Way Handshake and other payloads where the entire MTU fits into a single Ethernet frame.  Figure 6.1b is the extended Ethernet Frame that is used for inter-layer status or network information protocols like as ICMP and others.  The extended control fields are the Source Service Access Point (SSAP) Destination Service Access Point (DSAP) for inter-layer communications.  Figure 6.1c is the extended Ethernet frame generally used for larger segmented payloads such as HTML, FTP and others.  The extended control fields are the Source Service Access Point (SSAP) Destination Service Access Point (DSAP) plus the Subnet Access Protocol (SNAP) control to keep track of the segmentation of the data transferred.  The headers shown in Figures 6.2a, 6.2b have a fixed format up to Octet 21, the variations in header structures are defined by octets 20 and 21 and determine the remaining structure, hence: the data/payload section.  Table 6.2 is a list of the variations for the Type/Length field to determine the full maximum length of the header.  The extended fields will be covered later in the series with the inter-layer communications and data segmentation, for this part of the series we are presenting the Ethernet format structure and device to device data transfer.

The Ethernet Cable Length Defined
There are many variations and opinions of what the maximum physical length of the Ethernet over twisted pair cable should be, however the variations are set by the cables category ID from Cat3 through Cat8 which all incorporate the same modular connector defined as an 8 Position 8 Contact (8P8C) connector.   The physical length of the cable is dependent on the category ID and drive capabilities of the hardware it is connected to.  The standard length of the cables for Cat3-Cat6  for their assigned speed is 100 meters, Cat8 is 30 meters for its 25-40Gbps BASE-T speeds and only operates in full-duplex mode.  Technically the full analytical derivation for cable length is beyond the scope of this series however, cable length parameters are derived from several physical characteristics that include, twisted pair capacitance per foot, shielding separate pairs or if only one shield, cross talk capacitance between pairs, cable resistance ohms per foot, number of strands in the standard topology or diameter for solid wire,  signal voltage swing peak to peak, and the source power available for driving the signal, the switching frequency of the signal-10Mbps, 100Mbps, 1Gbps etc. are the main parameters taken into consideration to determine the length.  The industries standard length of 100 meters (328 feet) between device to a switch port and down link switch port to an up link switch port  are confirmed by all equipment manufacturers at this time.  There exists custom equipment that allow much longer lengths however it would be easier, cheaper and better QoS to just add a switch or RJ45 active cable extender to obtain longer lengths.

Some Computer History: How The Bit Assignments Nomenclature Changed
Back in Part-4 IP Header Formats we mentioned the Bit assignment nomenclature being reversed so to put this in perspective we will take a trip down memory lane for us seniors and ancient history for the younger.  To start the Binary Base2 system has not changed and goes back to the 1600 if not further, however it was introduced to the digital world with a relay-based computer in the 1940's along with the nomenclature weighting of the base2 number system,  2n + 2n-1 +.....+ 21 + 20  where 20=1, 21=2, etc  as 1, 2, 4, 8, 16 etc. Left to Right Most Significant Bit(MSB 2n) to the LeastSignificant Bit (LSB 20) so the original nomenclature was weighted similar to the decimal number system right to left increasing number,  the bigger n is the larger the number is.  OK, now the change, when the major minicomputer was introduced in the late 1950's by Digital Equipment Corporation (1950-1990) known as DEC or Digital the bit assignment nomenclature "only" was reversed as  20 = highest bit number number and 2n = 1 the lowest bit number on the computer switch panel, however the binary base-2 number system did not charge it was just the way DEC's nomenclature was introduced.  In 1968 this changed again with the introduction of the 16 bit computer from one of DEC's digital engineers that left and started Data General Corporation (1968-2002).  The bit assignments nomenclature was changed back to the original base2 nomenclature for 15-00 where 15 = MSB ( 215) and 00=LSB (20 ) with the weighted decimal system where  20=1.  To add a bit to the confusion the computer word was segmented into three bit blocks  for an base8 (octal) notation.

Remember that the bit assignment nomenclature is only a nomenclature and may or may not represent the true form of the bits being transmitted.  For the Ethernet Frame Bits are placed on the bus the Least Significant Bit (Bit7) first.  This does not change the actual number it just brings it back into the standard serial methodology.  So to sum this role reversal, in the real digital world serial data is placed on the bus MSB first and shifted left so the bit notation is MSB(27)-LSB(20) left to right where bit 7 is the real MSB and the binary data is read and weighted the same way the decimal system is weighted.  In the Internet world because of the bit reversal the data is placed on the bus Least Significant Bit  (bit 7) first and the bit notation is LSB(20)-MSB(27) left to right.  Sort of a long way around for the bits to be read into the device and ends up in the real digital world weighted format the way it should.  This will have more meaning when we are in the hardware design section of the series which will show that many chip devices that support serial protocols have different MSB/LSB transfer formats.  Therefore the actual Ethernet Preamble + SFD real world data read by another device will be 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5 hex format or 85 85 85 85 85 85 85 213 in decimal format.   The SFD 0xD5 byte signals the start of the octet data to be read.  This will all fall into place when we setup the header structure shown in Figure 6.2a and Figure 6.2b for programming the Ethernet Frame in the software section of the series.

EthernetFrameBlockHeader
Figure 6.2a  802.3 Standard Ethernet Header Frame Structure

EthernetFrameBlockHeader_SNAP
Figure 6.2b  802.3 + 802.2  Ethernet Header Frame Structure
Source Service Access Point (SSAP)
Destination Service Access Point (DSAP)
SubNetwork Access Protocol (SNAP) Control

The Ethernet network topology changed the way we connect devices on the Local Area Network.  The old coaxial cable we just paralleled each computer to the same cable it was cumbersome to work with and the cable loading factors were difficult to troubleshoot among other difficulties.  With the RJ45 Cat5[6] twisted pair cables we use a multi-port Network Switch to connect devices single port - single device.  The variations in speed and mode hence, 10/100/1Gbps Base-T, full/half duplex NIC's are handled by the Network Switch where each device is connected to a single RJ45 port on the switch.  For each device the switch allows it to run in half or full duplex depending on the NIC and only sends the data to the destination port by keeping track of the MAC address for each device connected to the same LAN; half duplex is rarely used today in Local Area Networks.  We will cover switches in more detail later in the series.  For now the basics are, switches maximum speed defines network speed regardless of the NICs in the devices connected to the switch ports;  the devices maximum speed is set by the NIC regardless of the maximum speed of the switch.  On a multi-speed switch each port may run at the negotiated speed of the NIC on that port.

Will The Ethernet Physical Layer Protocol Please Stand Up:
As shown below in Table 6.0 the IEEE 802.xx Hardware protocol has been around for some time and have been updated to address new transmission demands.  For this part we will focus on the IEEE 802.3 Ethernet specification.  The light green background protocols are the ones we would like implemented into the IoT  Core Platform.  The IEEE 802.3 specifications have been upgraded over the years (1983 - 2017) and expectations up to 2019 to handle the variations in connectivity and speeds up to 40G bps.  The design methodology of the IoT Platform will incorporate the flexibility for the implimentation of additional hardware protocols as they are required for the application.

Active Working Groups

Name

Description Note
IEEE 802.1 Higher Layer LAN Protocols (Bridging) active
IEEE 802.3 Ethernet  Original Specification 1980 - Standard in 1983 active
IEEE 802.11 Wireless LAN (WLAN) & Mesh (Wi-Fi certification) active
IEEE 802.13

Unused[2]  for Fast Ethernet development[3]

Reserved
IEEE 802.15 Wireless PAN active
IEEE 802.15.1 Bluetooth certification active
IEEE 802.15.2 IEEE 802.15 and IEEE 802.11 coexistence  
IEEE 802.15.3 High-Rate wireless PAN (e.g., UWB, etc.)  
IEEE 802.15.4 Low-Rate wireless PAN (e.g., ZigBee, WirelessHART, MiWi, etc.)  
IEEE 802.15.5 Mesh networking for WPAN  
IEEE 802.15.6 Body area network  
IEEE 802.15.7 Visible light communications  
IEEE 802.16 Broadband Wireless Access (WiMAX certification)  
IEEE 802.16.1 Local Multipoint Distribution Service  
IEEE 802.16.2 Coexistence wireless access  
IEEE 802.17 Resilient packet ring hibernating
IEEE 802.18 Radio Regulatory TAG  
IEEE 802.19 Coexistence TAG  
IEEE 802.20 Mobile Broadband Wireless Access hibernating
IEEE 802.21 Media Independent Handoff  
IEEE 802.22 Wireless Regional Area Network  
IEEE 802.23 Emergency Services Working Group  
IEEE 802.24

Smart Grid TAG   - New (November, 2012)

 
IEEE 802.25 Omni-Range Area Network  

Inactive / Old Working Groups

IEEE 802.2 LLC disbanded
IEEE 802.4 Token bus disbanded
IEEE 802.5 Token ring MAC layer disbanded
IEEE 802.6 MANs (DQDB disbanded
IEEE 802.7 Broadband LAN using Coaxial Cable disbanded
IEEE 802.8 Fiber Optic TAG disbanded
IEEE 802.9 Integrated Services LAN (ISLAN or iso Ethernet) disbanded
IEEE 802.10 Interoperable LAN Security disbanded
IEEE 802.12 100BaseVG disbanded
IEEE 802.14 Cable modems disbanded
     

Table 6.0  The variations of the IEEE 802.xx Protocol Specifications

Ethernet Frame Fields Description
The Ethernet Frame Fields are listed in Table  6.1 below showing the standard 802.3 field definitions.  There exists an extension of 802.3 that adds an additional four octets that attaches some Subnet identifiers 802.1Q tags that support Virtual LANs (VLANs) over an Ethernet Network. We will address this during the software protocol implementation part of the series.  For now lets focus on the standard Ethernet 802.3 to set the ground floor of our understanding to grow on.  The two main fields that require some thought are the Type/Length and the Payload fields.   The Type/Length field (16 bits) 2 Octets has gone through many updates and additions over time as the list of field parameter values show in Table 6.1 below.

Octet [Fixed Fields]

Size

Name

Description

00-06

56 bits
7 Octets

Preamble

10101010-10101010-10101010-10101010-10101010-10101010-10101010 Binary    0x55 0x55 0x55 0x55 0x55 0x55 0x55  hex

07

1 Octet

Start Frame Delimiter SFD

10101011 Binary    0xD5 hex

08 - 13

6 Octets

Destination MAC Address NIC MAC Address of Destination

14 - 19

6 Octets

Source MAC Address NIC MAC Address of Source

20 - 21

2 Octets

See Table 6.1

Ethernet II type - This is for this series  [+4] - 802.1Q if implemented + 802.2

Octet [Variable Fields] Size

Name

Description

22 1 Octet SSAP - Source Service Access Points LLC- Logic Link Control 802.2 Figure 6.1a
23 1 Octet DSAP - Destination Service Access Points

LLC- Logic Link Control 802.2 Figure 6.1a

24 - 25 1 or 2 Octet Control

LLC- Logic Link Control 802.2 Figure 6.1a

26

5 Octets

SNAP - SubNetwork Access Protocol

SNAP - Subnetwork Access Protocol  Figure 6.1b DSAP-SSAP

22-1521 or [27-1528]

46-1500 Octets

Payload Data Variable Payload  must be 46 bytes minimum up to 1500 Bytes Maximum

1522-1525 or [1529 -1532]

4 Octets

Checksum Checksum of all bytes in the header

-

12 Octets

Inter-Packet Gap  - Idle Time   (End of Transfer ID) Not part of checksum - This is just Idle inter-Packet Idle Time to separate packets.

Table 6.1  Ethernet Structure Field Assignments IEEE 802.3

The parameter values listed in Table 6.2 only reflect the parameters we are currently interested in for the IoT Core Platform development.  Presently there are about 50 different Ethernet Type parameter ID that have been defined and available for implementation into the 802.3 protocol.  Depending on the IoT Core Platform applications we leave this open for future implementation.

Ethernet Type Protocol Description Ethernet Type Protocol Description
0x0800

Internet Protocol version 4 (IPv4)

0x8844

EtherCAT Protocol for Automation

0x8006

Address Resolution Protocol (ARP)

0x88B9

GSE (Generic Substation Events) Management Services

0x0842

Wake-on-LAN

0x8892

PROFINET Protocol

0x22F3

IETF TRILL Protocol

0x88A8

Provider Bridging (IEEE 802.1ad)

0x22EA

Stream Reservation Protocol

0x88E5

MAC security (IEEE 802.1AE)

0x8035

Reverse Address Resolution Protocol

0x88F7

Precision Time Protocol (PTP) over Ethernet (IEEE 1588)

0x8100

VLAN-tagged frame (IEEE 802.1Q)

0x891D

TTEthernet Protocol Control Frame (TTE)

0x8204

QNX Qnet

   
0x86DD

Internet Protocol Version 6 (IPv6)

0x8863

PPPoE Discovery Stage

0x8808

Ethernet flow control

0x8864

PPPoE Session Stage

0x8809

Ethernet Slow Protocols

   
0x8847

MPLS unicast

   
0x8848

MPLS multicast

0x9100

VLAN-tagged (IEEE 802.1Q) frame with double tagging

Table 6.2  Ethernet Structure Type/Length Field Assignments IEEE 802.3

If  DSAP and SSAP are both 0xAA then SNAP is active which incorporates an IEEE 802.2 attachment protocol which we will cover during the software protocol part of the series since it involves other layers of the OSI model.  The typical IPv4 Ethernet-II from Table 6.1 above uses 0x800 for the standard protocol header and 0x806 for ARP discussed in Part-3 and 4 of the series.  For this section lets just focus on the standard IPv4 802.3 and use 0x800 as the Type/Length to construct the Ethernet Header to talk to other devices on the network.  On the issue of MAC addresses which is how the Ethernet LAN communicates to devices the MAC is assigned

MAC address assignments for manufacturers desiring to incorporate Ethernet controllers in to their products should obtain a manufacturer ID from the IEEE Registration Authority.   Ethernet controller chip ICs purchased from chip manufacturers generally require the user to supply a MAC address in order to use them.  MAC addresses are unique on a network just as IP addresses are unique for the Internet as we discussed earlier in the series.  IPv4 as we discussed only require a MAC to talk to the LAN, however IPv6 uses the MAC address as part of the unique IP address.  The data/payload is the only area that decerns the IPv4 - IPv6 schemes and any additional protocols.

IoT Core Platform Network Switch Connection: The Ethernet RJ45 10/100/1Gbps BASE-T
The structure for the Ethernet header is constructed depending on the protocol format being used.  Since there are separations for IPv4 and IPv6 as well as SNAP we would be implementing these separately and will cover these in the protocol software section of the series.  At this time we would like to bring up how the IoT Core Platform is intended to be connected to the LAN for both IPv4 and IPv6.  The connection methodology is intended to be wired RJ45 twisted pair cable, Wireless WiFi and Bluetooth. through a multi-port switch.   This brings up the Switch technology today that has improved to the point that the LAN does not require a separate HUB or run in half duplex for an effective LAN.  Switches have several basic features that help control traffic throughout the network.  Since a single device is connected to a single port each switch port maintains a MAC address buffer and is able to connect only to the destination device without interfering with other ports.  This allows better control over collisions as well as less interaction with the router which increases throughput when accessing the Global Internet..  Figure 6.3 is a typical IoT Platform connected to a multi-port switch, each platform device has its own port on the LAN.  Switches have two categories, managed and unmanaged where the majority of home Internet networks use unmanaged switches.  The main difference is managed switches allows user control of network traffic ports configuration and the unmanaged is a predetermined fixed configuration for traffic flow.  Figure 6.3 shows a typical eight port switch connected to several devices.  We identified each of these devices MAC address to show how the typical switch handles traffic device to device.  We setup a source and destination MAC address and filled in a Ethernet Header as it would be extracted from a TCP header and sent to OSI Layer 2 Data Link.  The captured data shown in Figure 6.4a is the sender(outbound ) traffic data to the switch port 6 and Figure 6b is the destination( inbound) traffic data.  Since one of the features of the switch is to strore the IP and MAC addresses for eachj of the switches port, these will be listed with the captured data.  The switch actually decodes the destination MAC address and it opens on;y the destination port to send the data to.  Since this was from a TCP handshake protocol sequence the IP are listed as part of the capture however, only the MAC addresses are used in the actual device to device on a Ethernet LAN.

IoTPlatform_Switch
Figure 6.3  Physical Cat6e Cable Connection 8 Port Switch

Ethernet Communications Device to Device Captured on LAN
The LAN connected devices in IPv4 & IPv6 communicate via the MAC addresses, there are no IP addresses in the Ethernet Physical Header.  This means one can easily talk device to device just using the Ethernet Physical Layer Header and supply unique data for each device.  We will look at this in more detail when we cover LAN based Industrial Control Networks as the series moves forward.  Figure 6.4a and 6.4b are the captured Ethernet Frame outbound at Source to Inbound at Destination through the switch using a typical packet capture program.   As we see there are no IP addresses required to setup the Ethernet Frame and transfer data to other devices on the LAN.  The network used to collect this data was a 1Gbps BASE-T using an unmanaged switch.  The MAC addresses are assigned to Intel Corporation as are the Network Interface Controllers on two different systems.  The two devices send data and confirm the same data to insure a link.  The Type/Size is x800 which is Internet Protocol version 4 from the above table.  The captured Ethernet packets shown below Figures 6.4a abd 6.4b will not show the first 8 bytes or the IPG 12 bytes since they are the Identifiers for synchronize and end data collection and are not part of the frames device data. The size of the data payload is also tracked and displayed, the firewall on the system allowed this data to be collected from Source to Destination.  

EthernetCaptureFrameOut
Figure 6.4a  Captured Ethernet Header Frame Outbound

For MTU's less than the 1500 octets/bytes the data fits into the Ethernet Frame and only requires a single transport cycle.  Notice that the Inbound and Outbound traffice the MAC addresses have been reversed.  This communications was a ping test for the server and workstation confirmation of connection.  The system use for this series series was assembled specifically for the development of this IoT Core Platform series for continuity.  The system configuration consists of an Intel Server dual Xeon 64 bit processors with Hyperthread running Redhat Enterprise Linux connected to two workstations two Windows XP-Pro x32 bit and a Windows 10 x64 bit system.  The IoT Platform series network is a stand alone Client / Server configuration that is not connected to the Internet.

EthernetCaptureFrameInbound
Figure 6.4b  Captured Ethernet Header Frame Inbound


Summary for Part 6:

  • All serial hardware protocols have to have some methodology to identify a starting point for the data transfer and the end of the data transfer, as well as when each bit is valid to be sensed.  

The Ethernet Protocol hardware characteristics incorporates the following capabilities and features:

  • a differential twisted pair configuration for Transmit and Receive lines.
  • a variable length protocol - the payload varies from 46 bytes minimum to 1500 bytes maximum with an added eight bytres (802.2, 803.1Q) for inter layer links if incorporated.
  • an internally hardware controlled asynchronous autonegotiation protocol - uses 8 bytes to determine configuration and 12 idle bytes to end data transfer.
  • auto-configuration to run Full or Half duplex  for the 10/100 BASE-T,  1Gbps BASE-T and above run in full duplex only.
  • Ethernet switches internally maintain the devices IP and MAC address of devices connected to each port.
  • a mechanism through Ethernet switches allowing device to device communication without router intervention.
  • MAC addresses must be unique to the connected LAN devices.
  • Manufacturers must be assigned a block of MAC addresses along with a manufacturer ID.
  • The Ethernet Controller requires eight octets, a  block of 31 sets of state changes 1's and 0's to configure the controller for the start of the data
  • The Ethernet Controller requires a block 12 idle states to identify the end of data transfer.

Part 7 overview will cover a continuation of the Ethernet Frame
Now that the core structure of the Ethernet Physical protocol has been presented as a data transfer protocol we will present the following to finish up the Ethernet Physical protocol presentation.

  • CRC - Cyclic Reduncancy Check basics
  • Why do we use CRC's
  • Basic polynomial multiply/divide and XOR algorithms for the Internet
  • The CRC-32 for the Ethernet Protocol Frame
  • The Checksum for the TCP, UDP & ICMP Protocols
  • Another look at checking the integrity of data IP, TCP, UDP, ICMP protocols
  • A look at other protocols Checksums CRCs and data integrity mechanisms
  • A brief introduction to the embedded processor market and the process of selection
  • A brief introduction to Ethernet controller IC's
  • A brief introduction of other peripherals for the IoT Core Platform

Reference Links for Part 6:
The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site. The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery:  http://www.networksorcery.com
The Internet Engineering task Force:  IETF - RFC references
Wikipedia  https://en.wikipedia.org/wiki/Main_Page


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-6 The Ethernet Protocol (s): Lets Sync Up- (Sept 24, 2017)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=11&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-6 IPv4, IPv6 Protocols, Network Transport & Applications: <i>Continued (Sept 24, 2017)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-5

saltuzzo | 21 August, 2017 12:30

Part 5: IPv4, IPv6, Protocols - Network, Transport & Application: Continued
Protocol, Protocol, Protocol, Lets Sync Up

When a Man's knowledge is not in order, the more of it he has the greater will be his confusion - Herbert Spencer

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 IPv4 & IPv6 Protocols - Network, Transport & Application (January 10, 2017)
Part 6 IPv4 & IPv6 Protocols - Network, Transport & Application Continued (Sept 24, 2017)

Quick review to set the atmosphere for Part 5
From the previous Internet of Things Part-1 through Part- 4:

  • We have presented the basics of the Internet and established that the Internet is just a transport agent of the "Information Highway" and the IP address is just a single point on that highway.
  • Internet Protocols are a methodology or a road map for the transport agent to carry the information payload from point A to point B for IPv4 or IPv6.
  • The IP scheme identity is defined by the first 4 bits of the IP header, of the 16 available network identities 14 are available for networks, Identities 0x0 and 0xF are reserved.  IPv4 identity is 0x4 and IPv6 identity is 0x6. The remaining schemes are ST (State Datagram Model) = 0x5, defined in RFC1819 as an attempt to stream data and control QoS (Quality of Service). The ST protocol is not used much at this time.  PIP (Private Internet Protocol) = 0x8, defined in RFC1621 - RFC1622,  TUBA  (TCP+UDP+Big Address) = 0x9 defined in RFC1561  as a CLNP(ConnectionLess Network Protocol) and TP/IPC (TP/IX)  (Transmit Protocol / Inter-Communications Protocol) = 0x7, Next Version Internet defined in  RFC1475.
  • We presented the IPv6 dual-stack or tunnel that connects IPv6↔IPv4 Point-2-Point assignment in order for IPv4 only networks to coincide with IPv6 networks using a block of IPv6 addresses assigned as ::FFFF:[IPv4 address], the long form being represented as 0000:0000:0000:0000:0000:FFFF:xxx.xxx.xxx.xxx.  IANA assigned ::FFFF:hhhh:hhhh to uniquely identify the IPv4 only addresses that are not IPv6 aware. This is one of the few times both hex and decimal notation are used in the same number.
  • We presented the throughput and bandwidth issues that, unfortunately will always be an active issue within the Internet environment for either IPv4 or IPv6 schemes or any other scheme implemented that requires an ISP to use. The bandwidth issue is due to the fact that bandwidth is an "income producing product" for Internet Service Providers, the more bandwidth the faster throughput, the higher monthly charge for the connection.
  • We presented an overview of  the list of protocols that IPv4 and IPv6 are able to handle as well as an overview of the list of protocols we wish to initially implement into our IoT Core Platform.

What we want to cover in Part 5:  Still More Protocols
 The Internet runs on "Protocols", yes, the slogan was a well known commercial and acknowledged for the creators innovation.   The statement for the Internet is absolutely true, the Internet IPv4 or IPv6 in this series runs on protocols period.

  • First we will cover an important documentation feature of the Internet schemes, the "Request For Comment" (RFC)
  • Packet Switched Networks - The Internet uses data packets to transport information from point A to Point B.
  • The TCP/IP Internet Suite's four layer grouped OSI model and the main protocols associated with each layer for this series.
  • Briefly investigate the physical network layer's serial data stream that is placed on the network to communicate with other computers, devices and different network topologies. A detailed presentation on the physical layer will be presented during the hardware design stage of the IoT Core Platform.
  • Present more about protocols, how they differ and how they are incorporated into the data flow for the TCP/IP Internet Suite four layer model.
  • Present two protocol categories one that uses the IP header and one that does not use the IP header and the implementation stimulus/response with the TCP/IP OSI  Model.  
  • Present a typical protocol format of the categories that will provide an understanding of the Internet schemes as well as set a format for the protocol requirements for the IoT Core Platform.

Lets Get Started: Request For Comment (RFC)
One of the most important guides to understanding and implementing Internet protocols are the associated RFC's (Request for Comment) documents.  These plain text documents can be read with any simple text editor like Windows Notebook or Linux Kedit.  RFC's are not the Internet's Standards however, when a standard is agreed on by the Internet standards committee groups and validated it usually has an RFC associated with it.  RFC's are works in progress in order to establish guidelines for testing, implementing headers and data structures of a protocol or function of the Internet.  RFC's are the most scrutinized documents associated with the Internet's operations and go through a series of changes, testing, and processes before being submitted as a possible standard.  There are also propriety RFCs that have been established by manufacturers of custom and advanced routers like Cisco® and require permission to be used by other manufacturers.  So we will be careful as not to create any new RFC's during this series.  A complete listing of RFC documents may be found on the IETF website linking the RFC index  or a categorized index at the http://www.networksorcery.com/enp/rfcs.htm There are many RFC documents and are categorized as Internet StandardsBest Current Practices and FYI For Your Information., browse these at your convenience.

Four Layers Of The Shared OSI Model: The TCP/IP Internet Suite
There are many experimental networks being developed internally on a closed network that are not publicly released.  Anyone with detailed network knowledge can develop there own internal network with customized routers for experimenting however, if you want to use the Global Internet you have to use one of the active schemes in order for the routers to transport the packets.  The developer may also request a new protocol to be added to the Protocol ID table in one of the 200+ unassigned ID's by submitting the details to the IETF for review.  The concept to keep in mind when sending data over the Internet is, if a router in the Source to Destination path does not understand the data being presented due to errors in format setup or a protocol the router will dump the entire packet at the impasse into the "black hole" of the Internet and terminate the transfer, at which point the router may or may not send a flag that the process failed back to the sender. The termination is different from the the initial connection synchronization from Source-Destination.  Figure 5.0 is a typical Point-to-Point connection showing that routers are the bridge trolls between Point A and Point B and are required to interpret all commands and functions to complete the process.

    Point2Point.jpg
    Figure 5.0  Typical Point-to-Point Connection Through Routers

Before we dive into the OSI model structure we should look at how the information flows between the nodes connected to it.  Figure 5.1 Point to Point OSI Model Data Flow review shows the Encoded side and the Decoded side of the data path.  All information that flows through each end of the model has some sort of data attached.

InternetDataPathFlow
Figure 5.1  Protocol Headers Typical Format

Of the seven layers of the TCP/IP Suite OSI model there is only one hardware layer, the Physical Layer -1. This Physical layer -1 does incorporate protocols however, the protocol is a hardware specification that identifies how the serial 1's and 0's are transferred from device to other devices connected to the same network  The remaining layers 2-7 are software layers that consists of various protocols.  The software controlled layers are the Applications, Transport and Inter-Network layers, the hardware controlled layer is the Data-Link that drives the Physical layer.  Data flow is dependent on the protocol(s) used and encoded as it passes through each layer based on the required protocols used in each layer.  Some protocols are kept on the LAN (Local Area Network) side of the network and not passed through the networks router, while others are passed through the router to the Global Internet ISP router to reach a destination that is outside the LAN connections and should or will return a status and/or other network information to complete the request. OK, that is a bit general, we will break it down shortly.

The Internet protocols are application evoked and are setup for many different network applications; by the end of this series we will understand the handling of protocol processes through the most common used TCP/IP Model.   Protocols are no different that any other software application transferring data, be it the Internet or some internally developed proprietary topology except for the fact that the Internet Protocol Suite is a fixed standard format that once set may be used throughout the millions of routers connected to the Internet.

To show how the TCP/IP OSI Model functions in the real world, a presentation of the four layers with selected protocols we will construct a data flow example through each layer.  Each of the software controlled layers have many protocols assigned to it for many applications.  As we discuss each of the four layers we will present a link that will contain all the protocols and data applied to each layer.  During the presentation we will only list the protocols we will be concerned with in this series.

Keep in mind protocols are just a fixed header format used to identify the data block attached being transported between a source and destination and is given the label name the Protocol Data Unit (PDU).  Protocol headers are the first bits of information being translated as it enters the layer and identifies how each layer is required to handle the attached  "Data / Payload or Datagram" for the next layer in the model.  Figure 5.2 shows the protocol headers typical format and the relationship to the Protocol Data Unit (PDU).

Protocol_Data_Format
Figure 5.2  Typical Protocol Header Format
 PDU (Protocol Data Unit)

Internetwork Link Layer: Shared Data-Link Layer and Physical Layer
This Internetwork layer is where the full frame of the data packet is encoded/decoded, transmitted/received over the physical network (the 1's and 0's serial data stream), be it CatDx cable, FDDI, SONET, Coaxial cable or other types.  Each physical network topology has a fixed hardware protocol specification in order to maintain synchronized communications with minimum collisions from other devices connected on the same network.  

The Data Link layer conditions the packet data to conform to the physical layer data transfer specification.  Keep in mind that there are many different physical layer network topologies and there exists a hardware protocol specification identifying how data is to be processed through it.  Some different network topologies are, WiFi b/g/n, Ethernet, Token Ring, Bluetooth, SONET and others.  All physical layer topologies require some type of synchronous or asynchronous handshake in order to connect to other devices on the network.  

The IoT Core Platform will incorporate an Ethernet network medium interconnect through an RJ45 connector using a Cat6e cable to support a 1Gig bps data transfer.  The Ethernet Packet Frame for the Physical Layer Header Format is shown in Figure 5.3A  how data flows on to the network medium to establish communications over the attached network.

Ethernet_Frame.jpg
Figure 5.3a  Physical Ethernet Layer Frame

Hardware selections and communications for the network interface topologies will be covered in the Hardware, Software and Firmware sections of the series.  For now we will look at the Data-Link / Physical Layer as a simple bi-directional data block that transports data over the Internet as shown in Figure 5.3b Physical/Link Layer Block Diagram below. The complexities of the hardware for the physical layer primarily resides in the hardware category while the protocols being presented reside in the software category and have different process handling.

LinkLayerBlk.jpg
Figure 5.3b  Physical / Link Layer Block Diagram

Due to the fact that hardware protocols are in a fixed medium specification category for transferring data allows network topologies to be connected together with a series of hardware/firmware interfaces that convert one transmission medium to another as required by the environment at hand.  This flexibility allows the "Information Highway" to be a global network converting many types of  network hardware topologies to interact reliably.  Since the physical network topology is only used at the physical hardware level for transporting information the medium headers are stripped from the frame and only the Internet packet information is what is passed through the remaining layers.  As stated we will cover the physical medium in detail during the hardware design part of the series.

Internet Layer: Shared Networks Layer 3 and Data-Link Layer 2
The Internet layer is a group layer that overlaps the input section of the Data Link Layer since the data output of the Network Layer must provide the proper data stream for the physical connection.  For our series we will concentrate on the PPPoE (Point to Point Protocol over Ethernet).  The importance of this protocol is that it allows a connection and authentication between two routers without any host or other layers protocols or data.  In our previous part we stated that the Internet is a Point-to-Point scheme, it requires Source and Destination addresses in order to complete the transaction.  The overlap of the Network and the Data Link layers allow the use of other TCP/IP Internet Suite protocols like OSPF (Open Shortest Path First), RIP ( Routing Information Protocol) and IS-IS (Immediate System to Immediate System).  This layer has also incorporated a protocol to allow end to end notifications of network status such as network traffic congestion without dropping packets.  ECN (Explicit Congestion Notification) must be router enabled at both ends in the router in order to function.  There are more protocols for the Internet Layer depending on the Internet scheme version selected. A link for a full list refer to Internetwork Layer Protocols.  There are also propriety protocols that are owned by router manufacturer companies that reside in this layer as well and may not be available in other manufacturer's routers,  we will cover some of those propriety protocols later.  

ICMPv4 and ICMPv6 Protocol Header
The ICMP (Inter Control Message Protocol) is a support protocol used for network information and status for routers and hosts to inform the sender that the destination could not be reached and other status information.  Generally it does not exchange data from host to host just from network routers to host.  Figure 5.4 shows the ICMP header fields that are the same layout for both ICMPv4 and ICMPv6 and each have their own field notation.

ICMP_Header.jpg
Figure 5.4  ICMPv4, ICMPv6  Packet Format Field Assignments

What makes this layer interesting is it shares part of the Data-Link layer, interesting because the Data-Link layer also is shared with the Physical layer and the interaction allows specific protocols like Multi-cast, Broadcast and Unicast and Anycast without the OSI's strict header requirements as with other network schemes.  Communications for these types of protocols are handled router to router and device to router and back to device without host intervention.  The router in many of these cases handle network scanning of devices connected and returns requested network status information to the sender.  Some protocols require the host keep track of devices connected for inter-communications over a LAN as is with IPv4 that keeps the network users IP and associated MAC addresses in a buffer within each networks connection Operating System.  The field parameters are available several places on the Internet and may be viewed through the links,  ICMPv4  RFC 702  for IPv4 and ICMPv6  RFC 4443 for IPv6.  Field assignment parameters cover the full capability of the protocol, we will cover a simple implementation to understand the flow of the protocol at this time in the series.

End to End Layer:  Shared Session Layer 5 Protocols and Transport Layer  4 Protocols
There are a few protocols that are mostly used within this layer, they are shown in Table 5.0 End-to-End Layer Protocols.  Our intent is to show how protocols are implemented in order to have a flexible IoT Core Platform that is capable of incorporating protocols as needed for any specific application.  We will cover only the Transmission Control Protocol and User Datagram Protocol for this part of the series to understand the typical protocol implementation process.

Protocol

Full Name

Description Summary

TCP

Transmission Control Protocol

TCP is the dominant protocol that provides reliable, ordered packets with error checking and congestion control delivery between hosts over an IP network.

UDP

User Datagram Protocol

Used to send message(datagrams) to other hosts point to point IP network. Direct point to point data paths.

SCTP

Stream Control Transmission Protocol

A message based protocol for multihoming multiple IP to maintain connection for multiple streams of data end-to-end.

DCCP

Datagram Congestion Control Protocol

Provides a way to get congestion control without going through the Application Layer.

RSVP

Resource Reservation Protocol

Used to reserve setup reservations for multicast or unicast data flows- No data transport just setup routes.

Table 5.0  End-to-End Layer Protocols

TCP Protocol Header
The Transmission Control Protocol  RFC 675 December 1974 is without doubt the dominant protocol used throughout the Internet.   The field assignments are found in this link, TCP Field Assignments, of which we will break down and cover the categories of how this protocol functions through the End-to-End Layers as the series continues.  The TCP is the key synchronization protocol for creating a connection Source to Destination hosts on the Internet and uses the Internet's "Three-Way-Handshake"  that we will cover in the next part of the series.  The TCP incorporates ordered octets as well as error checking on hosts running applications through the IP network.  Web (HTML) applications, E-Mail(SMTP, POP), File Transfer(FTP) are only a few that rely on the TCP for accurate data transfer.  TCP also incorporates a congestion control methodology called Additive Increase / Multiplicative Decrease (AIMD) algorithm.  We will cover AIMD as well as  ECN (Explicit Congestion Notification) as we proceed through the series.  TCP has gone through many RFC revisions from its original 1974  IEEE publication A Protocol for Packet Network Communications, later renamed Transmission Control Protocol, the latest RFC-7414  Feb 2015.  The TCP header is shown in Figure 5.5 below.

TCP_Header.jpg
Figure 5.5  TCP Format Field Assignments

UDP Protocol Header
The User Datagram Protocol  RFC 768  is a quick non-critical, reduced latency data transfer protocol that is a connectionless datagram service that  is less reliable than TCP.  There is no handshaking communications between source-destination.  UDP does provide source- destination ports to handle several applications type protocols. The UDP header is shown in Figure 5.6 below.

UDP_Header.jpg
Figure 5.6  UDP Header Format Field Assignments

Application Host Device Layer:
Shared Application Layer 7 Protocols, Presentation Layer  6 Protocols and Session Layer 5 Protocols

The Applications layer handles a lot of the grouping of the users application data to be transported.  The TCP header is the same TCP header in Layer 4 and at this level the data is segmented or fragmented into smaller packets which the TCP keeps track of the data flow.  Streaming of the data flow is handled by a different set of protocols.  This is probably the most flexible area of the model since the user has more control of the data types as well as data manipulation to be transported as long as source encoding and destination decoding are a matched pair.  The initial protocols for this area to be incorporated into the IoT Core Platform are  BGP (Border Gateway Protocol) , SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), NPT (Network Time Protocol), PTPv2 (Precision Time Protocol Version 2) all having their own headers and application requirements, from a list of 100 plus protocols and there is still over 150 unassigned protocol IDs available for future development; protocols can easily become a career education in itself.  We will address the detail requirements to implement the above mentioned protocols during the Software/Firmware parts of this series as we design the code for the protocols.  Refer to the links provided for an outline of each of the protocols.  All of these protocols along with their organized header and field requirements may also be found at http://www.networksorcery.com except for the Precision Time Protocol that is an IEEE standard and may be found at IEEE-1588.  

For the IoT Core Platform as presented earlier to be used with multiple IoT devices in a range of applications for control we would require a precise time synchronization mechanism for multiple devices.  The NTP (Network Time Protocol) standard is a relative low resolution time synchronization and will synchronize many servers, desktops and devices to the second efficiently however, the Precision Time Protocol has accuracy capability in the sub-microsecond resolution for Local Area Networks.  The Application Layer is considered the User Data Segment (UDS) and contains the user data to be transported and does require an IP header associated with the Internet scheme being used.

Packet Switched Networks:
Application Layer, Transport Layer,  Network Layer , Physical Layer  = Protocol Data Units

Now that we presented the TCP/IP Suite grouped Four Layer OSI model we will present how the data is transported through the layers.  Since each layer is required to process the data that is attached to it independently of the remaining layers the IP scheme encodes/decodes a block or packet of data at a time. This packet has been given the name PDU (Protocol Data Unit).  The PDU allows each layer to attach routing, network and other information the protocol used on the current layer before sending the PDU to the next layer in the model.  The Source encodes each PDU and recombines them for transport to the Physical Layer (1's and 0's) and decodes each of the layers PDU in reverse order at the Destination as shown in Figure 5.1 above.  Table 5.1 shows the typical Protocol Data Units. PDUs are just a way of organizing each layer.

Layer Name

Data Block Name

Reference Info

Application Layer 7

User Data
FTP, HTTP, POPS

For HTTP it is a web html file, for POP it is a SMTP and Data PDU

Transport Layer 4

TCP = Segment,
UDP= Datagram

For TCP it is the TCP Header and Data, For UDP it is the UDP header and Datagram

Network Layer 3

Packets

The Network - IP header + Segment = Packet

Ethernet Layer Physical

Frame

Combined it is the Frame that is 1's & 0's

Table 5.1  PDU - Protocol Data Unit Each Layer

The processing of all the layers PDU's form a new network entity called the Switched Packet. The switched packet follows the physical layers requirements to transfer data on to the network and is givien a parameter called the MTU (Maximum Transmission Unit) which are all part of the Packet Switched Network block.  The MTU is the total bytes(octets) in a single Switched Packet that is transported over the network.  In order for the MTU to be transported it has to conform to the network topology it is connected to(the Physical Layer), this means it must be attached to a medium hardware and conform to the hardware protocol specifications in order to be put on the network.  Figure 5.7 below shows the relationships of the PDU, MTU and Frame.  Keep in mind that for very large data transports the Protocol Segment or PDU may be fragmented in which the Protocol Header will maintain the fragmentation counter and data pointers.  The local network medium will normally have some sort of start sequence to synchronize the beginning of the MTU data then have some sort of stop/end transmission medium synchronization usually with a checksum or some type of MTU data checking methodology to insure the frame was sent with no errors.

PDU_MTU.jpg
Table 5.7  PDU - MTU - FRAME  Relationships

Maximum Transmission Unit (MTU):  Protocols and the MTU
Since we covered the TCP/IP Internet Suite model and a few protocol formats it would make sense to have an ordered packet delivery mechanism regardless of the protocol header size.  The way that data is transported on a switched packet network is obviously by (wait for it) "packets", so now enters the Maximum Transmission Unit (MTU) which is the physical packet size in bytes.  Every network topology has an MTU and the size varies with the network topology.  Since protocol headers are a fixed size, then the size of the data has to be adjusted to the MTU size, hence, packing the packet.  For those packets that are less than the MTU the packet is zero filled, for the data size greater than the networks MTU fragmentation is required to transport the data.  The standard MTU size for the Ethernet topology switched packet network is 1500 bytes for the payload.  We would like to transmit packets that fit nicely into the MTU without fragmentation, however with today's data that is very rare.  MTU size is a function of the Physical Layer protocol as well as the network it is on.  

Table 5.2 below shows a few variations of MTU's with different network topologies.  The issues with MTU sizing is, if it is too small some protocols like IPSEC may not work well and if it is too large it slows the network due to long data transfer periods.  We will discuss this in detail when we enter the hardware section of this series.

Network Topology

MTU
Bytes

Reference Notes

Maximum MTU

65535

RFC1191 Maximum MTU bytes defined

IBM Token Ring -16Mbps

17914

RFC1191  variations are outlined in the RFC link

IEEE 802.4 Token BUS Network

8188

RFC-1042   variations are outlined in the RFC link

IEEE 802.11xxx (Wireless LAN)

2304

Media Access Control (MAC) and Physical Layer (PHY) spec IEEE-802.11 (2048 bytes data + 256 bytes layer protocol)

IEEE 802.5 (4Mbps) Token Ring LAN

17792

IEEE 802.5 - 17800-8bytes for LLC header

SONET

4474

4470 bytes Data, 4 bytes Header

Ethernet

1500

1508 bytes - 2 bytes for CRC and 6 Bytes for overhead = 1500

Point-to-Point PPoE Standard

1492

Total is 1500 - 8 bytes, 2 bytes for CRC and 6 Bytes for overhead

Point-to-Point PPoE Non-Standard

1500

RFC4638 non-standard frame of 1508 bytes - 2 bytes for CRC and 6 Bytes for overhead

IEEE 802.3 xxx

9000

Jumbo Frames - reference IEEE-802.3

SLIP / PPP

1500

Varies on Speed - Default 1500-8 = 1492 RFC-1055

Internet IPv4

 

Varies on Network Configuration  Min 68

Internet IPv6

 

Varies on Network Configuration Min 1280 RFC2460

Minimum MTU

68

RFC1191

Table 5.2  MTU Size For Various Network Topologies

 

Putting It All Together For The Next Part Of The Series:

  • The Internet Protocol is a "Packet Switched Network" Scheme as we see from above that the packet size varies for different network topologies.
  •  In order for different network topologies to be connected together an interface that converts one topology to another is required to insure that data transport integrity is maintained.  Many of these interface conversions are already in place today such as DSL, Cable, WiFi etc.
  • There are unique hardware protocols to synchronize data flow over the selected network topologies.
  • Each Layer of the TCP/IP OSI Model incorporates its own Protocol Data Unit (PDU) which is encoded by the Source (sender) and decoded by the Destination (receiver).
  • Each PDU has a protocol header to identify the protocol data attached to be processed.
  • Each layer of the TCP/IP OSI model determines if the data flow is completed and will end the connection or proceed to the next layer and handle the data for that layer.
  • There are many field assignments for the protocol suite that will take a fair amount of time to present them.  We will present the main protocols and their implementation into the IoT Core Platform, then as the series progresses we will add protocols by request of the readers.
  • As long as you follow the rules of the packet switched network and want to experiment with the different schemes you are free to use any of the available protocols, test the limitations and evaluate the performance.

Part 6 overview will cover a continuation of protocols
How the user data is synchronized and transferred through the OSI model layers.  The source/destination handshake connection process. How message protocols interact with the Internet routers and hosts for network status and information.  Selected protocol details, the TCP from point to point, The Unicast, Multicast protocols assigned IP addresses and expected responses from them. Once we cover the standard protocols and set the core process of how protocols communicate through different layers we will then begin the design process of the IoT Core Platform Hardware/Firmware and Software requirements.


Reference Links for Part 5:
The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site. The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery:  http://www.networksorcery.com
The Internet Engineering task Force:  IETF - RFC references
Wikipedia  https://en.wikipedia.org/wiki/Main Page


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-5 IPv4, IPv6 Protocols, Network Transport & Applications:  Continued

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=10&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-5 IPv4, IPv6 Protocols, Network Transport & Applications: <i>Continued (Aug 21,2017)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

 

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-4

saltuzzo | 10 January, 2017 09:27

Part 4: IPv4, IPv6, Protocols - Network, Transport & Application
Protocol, Protocol, Protocol, Lets Sync Up

An Investment in knowledge pays the best interest. - Benjamin Franklin

Personal note to the readers:
The Internet is an information playground for some and for others it is more than just a playground, it is a learning area for all types of knowledge to be applied and experimented with.  My experience over many years was the honor to be mentored by some of the most knowledgeable individuals in the industry. This series is dedicated in there honor, some of my mentors are not with us and are dearly missed however, the knowledge they shared with many is now the foundation for others to grow.

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 5 IPv4 & IPv6 Protocols - Continued
- Network, Transport & Application  (Aug 17, 2017)
Part 6 IPv4 & IPv6 Protocols - Network, Transport & Application Continued (Sept 24, 2017)

Lets Get Started:  Quick Review to Set the Atmosphere for Part 4
This educational series involves several disciplines and concepts that should be kept in mind while occasionally branching off in order to tie all the disciplines, concepts and strategies together; incorporating them into our main objective of creating a core IoT hardware/software platform that gives the user full control of security, privacy and configuration.  This part will be a reference section to the series since we will be returning to cover the set of selected protocols during the design and development process.

From the previous Internet of  Things Part-2 & Part-3 we have established that the Internet is just an "Information Highway" a transport agent, the IP address is just a single point on that highway and that the Internet Protocols are a methodology or road map for the transport agent to carry the application information from point A to point B.

We presented the fact that IPv4 is coming to the end of its addressing capacity and IPv6 will be replacing IPv4 eventually; holding your breath waiting is not advisable.  We presented the IPv6 dual-stack or tunnel that connects IPv6↔IPv4 Point 2 Point assignment in order for IPv4 only networks to coincide with IPv6 networks using a block of IPv6 addresses as ::FFFF:[IPv4 address], the long form being represented as 0000:0000:0000:0000:0000:FFFF:xxx.xxx.xxx.xxx.  IANA assigned ::FFFF:hhhh:hhhh to uniquely identify the IPv4 only addresses that are not IPv6 aware.  This is just a neglitable block of addresses to the overall address range of the IPv6 scheme.  To clarify this, the IP address 0000:0000:0000:0000:0000:0000:64.139.76.51 is a true IPv6 address and would be represented as ::408B:4C33 which is an IPv4 address and will function only if the connected devices are IPv6 aware.  BASIL Networks is an IPv4 only network and if you enter http://[0000:0000:0000:0000:0000:0000:408B:4C33] you would get a "Server Not Found" message from your browser, however if you enter http://[0000:0000:0000:0000:0000:FFFF:408B:4C33] the BASIL Networks web page will appear.  This is the IPv6↔IPv4 dual stack address translation block to handle all IPv4 addresses seamlessly.

We presented the throughput and bandwidth issues that, unfortunately will always be an issue within the Internet environment for both IPv4 and IPv6, also any other scheme that is implemented. The bandwidth issue is due to the fact that bandwidth is an "income producing product" for service providers.  The more bandwidth the faster throughput, the higher monthly charge for the connection.

Protocols: They're Everywhere, They're Everywhere! 
Protocol - Computer Science Definition - A specific set of rules defining a procedure for data transmission between computers (should be changed to devices to be more applicable today).  Protocols are one of the more challenging aspects of any communication process; some simple, some complex, confusing at times and they will without doubt challenge your mind and develop critical thinking with continuous probing and questioning subject matter; welcome to the world of communication protocols.

To narrow the protocol objectives for this series we will be focusing on the TCP/IP Internet Protocols Suite.  This is a unique group of TCP/IP protocols that are used throughout the Internet and required by every device that is "connected".  Protocols are part of the P2P pathways that allow communications though a series of connected routers, just like exits off highways, and are the backbone of the Internet.  Routers connect countries (Global ID), Internet Service Providers (ISP), SOHO, large companies etc. to a local user network down to the end point node, desktop, laptop or smartphone.

Routers that cross boarders into other countries, states and so on are all part of the "Information Highway" roadmap and are considered border crossings and are given the name Border Gateway Protocols (BGP) just like driving across borders where you have to pass through customs and if you break protocol while at the border you are detained.  When we discuss protocols for the Internet they are 99% software in origin, the remaining 1% are the hardware protocols which are fixed and relate to hardware interconnect methodologies at the data bit by data bit serial level such as RJ45 copper wired connector, Fiber Link optical connection, WiFi, Bluetooth, wireless connection and others.  Protocols, routers and devices inter communications are all interwoven throughout the Internet in various states and used to maintain the stability and uniqueness of every device on the Internet.  

In IPv4 devices on the LAN were configured on the LAN and communications data was Translated through NAT to the Internet Point to Point and the devices physical signatures were kept local to the connected LAN that the IPv4 routers controlled.  In IPv6 the device signatures now play an important roll in the communications throughout the Internet and are used to creates a unique IP address.

Before we get into the complex world of protocol details lets look at a high level overview of the Internet data flow.  Figure 4.0 shows the data flow of the "Hello World" phrase that is used in just about every compiler and assembler as a test case.  Our core IoT Platform requires an interfacing flexibility to be able to attach to any application, format the data from the application and transport it over the Internet to a specified destination.  This reduces down to two major components, the application interface for the sensors that generate the application information, and the network interface that the application information is attached to for transportation over the "Information Highway" the Internet.  The network interface we will be presenting is the TCP/IP OSI (Open System Interconnection) model as shown in Figure 4.1 by layers 1 through 7.  No data is transported without the use of protocols that are layered and grouped in the TCP/IP OSI model.   OK, now that we understand that the "Information Highway", Internet is a point to point transport agent or scheme lets inhale slowly and exhale slowly and get started.

Internet_Data_Flow
Figure 4.0  Internet Data Flow - TCP/IP OSI Model - Point to Point

Protocol Classifications: The TCP/IP OSI (Open System Interconnection) model
There are basically two classification types of protocols, hardware and software, wow just two? Yes, just two, Well then! guess it can't be that difficult to understand protocols.  Protocols are not difficult to understand, there are just a lot of them and sometimes grouped in the same block of data being transported.  The hardware protocols used may transport any type of network information on any type of scheme. What makes the hardware unique is the interaction of the network scheme being used, in our series this is the Internet IPv4 and IPv6 schemes.  The most common hardware protocol schemes are shown in Table 4.0 which are fixed hardware topologies that must have a fixed software interface to receive and decode the data.  There are NAD (Network Access Devices) such as switches, HUBs, Wireless Access Points (WAP); there are Inter-networking devices such as routers used to transport datagrams point to point. These Network Interface Controllers (NIC) rely on a stable crystal controlled reference to decode the serial bit stream for the communications.  There is no separate clock line to synchronize the data stream being transmitted or received, therefore the hardware decoding is defined as asynchronous communications, relying only on a start and end of a fixed bit stream length.  If the controller breaks the timing a network collision happens and the NIC sends a sync handshake stream back to the sending address to resend the packet/datagram.

Hardware Protocol Name Hardware Physical Interface Tx/Rx Range Interconnect Topology General Throughput Rate
Ethernet Twisted Pair RJ45
(Cat XX Cable)
200 Feet, 60 Meters+ Full Duplex 1, 2, to100 to 1000 Megabits/sec
FDDI (Fiber Distributed Data Interface)

Token Ring Dual Ring Tree  X3T12

200 KM, 120 Miles All RX / One TX - Half Duplex 32 to 100 Mbps
ATM (Async Transfer Mode)

SONET/SDH

200 KM, 120 Miles SONET Connector 155.520 Mbit/s OC3  to 38.48 Gbits/s OC768

Table 4.0  Common Hardware Interconnect Schemes

The TCP/IP OSI Model:
The OSI (Open System Interconnection) model is a general network model that is used throughout the industry to represent many types of networks.  Figure 4.1 shows how the OSI model layers are grouped and applied to TCP/IP Internet Protocol Suite showing their assignment to each layer which is commonly called the TCP/IP OSI model.  The design of protocols for the TCP/IP network OSI mode is a lot more flexible than the strict structure of other categories of  OSI model networks.  The IP addressing scheme is used primarily as a transport mechanism or agent and concerns itself first with the end to end encoding-decoding of the data, hence P2P.  The TCP/IP OSI model is grouped into four areas that overlap some of the seven OSI model layers when used with the TCP/IP Internet protocol scheme.  The Internet Link Layers,1 and 2 are a major concern since they deal with how the device(s) connected will coincide with other devices traffic, collisions and interactions.  Too many collisions or conflicting traffic yields poor QoS (Quality of Service) and degrades the overall network performance.  Poor QoS may also be due to many other areas such as poor wireless connection as too many walls between the wireless devices, poor cable quality for direct wired devices such as the wrong type of cable CAT5, 6 etc, or just poorly designed devices which is what we will assure will not happen with out core platform design.  The remaining three groups are used to encode-decode the data range and manage sessions on the network.  

For the TCP/IP OSI model there are four groups, one hardware group(physical layers) and three software protocol groups, the software groups are the NP (Network Protocols) which handles all inter router communications like the ICMP messaging that control and manage the network, the TP (Transport  Protocol) like TCP, UDP, which is used as a container to inform the router the type of protocol is being used to transport the user data information in the container, the AP (Application Protocol) like HTTP, SMPT, FTP, which is the actual data protocol the user data is formatted to that is inside the TP container.  Network protocols are fixed by IANA and ICANN groups and any new network protocols must be approved by those groups and registered with an RFC number before it may be used on the Global Internet. Private networks that are not connected in any way to the global Internet are open to experiment with different Application Protocols.  The Applications protocols are also IANA registered protocols however how the user formats the data within these application protocols is completely flexible and do not have to be registered.  This allows the user to transport raw, encrypted and/or formatted data P2P and process it accordingly.  All that is required is that the user follow the network rules for the NP, TP and AP groups.  Simple, just as you are reading this block with your browser, the maim port ID is 80 which is assigned the HTTP protocol and is in the application layer.

TCP_IP_OSI_Model
 Figure 4.1  OSI Model Layers with Associated Protocols

This brings us to the next step in understanding protocols, reviewing Figure 4.0 Internet Data Flow lets take a look at what actually flows over the "Information Highway" once it leaves the physical layer-1.  Since IPv6 is not fully implemented globally we have to take into consideration both IP schemes.  In order for these two different schemes to be recognized over the same transport agent lets take a look at the transmission format that is traveling over the network.

IP Header Formats: How the data is transmitted
All Internet network traffic is encapsulated in a network protocol block as shown in Figures 4.2, 4.2A & 4.2B, so lets take a closer look to see how this header identifies both IPv4 and IPv6 to seamlessly share the same network.  Keep in mind that Internet traffic is controlled or activated by addresses, so all we have to do is isolate a the control address block and give it a unique address like FFFF:[IPv4 Address] and it looks like an IPv6 address, then send it down the Internet for the routers to determine the type of scheme and the shortest path a different path for the block of ::FFFF: IPv4 addresses.

Figure 4.2 and Figure 4.2A shows the functional block diagram for all IPv4 Internet traffic and Figure 4.2B shows the functional block diagram for all IPv6 Internet traffic.  These control blocks allow many different protocols and data formats to be transported across the Internet, Figure 4.2 shows the IPv4 Network Protocols (NP) for communicating with other routers and servers.  Figure 4.2A shows the IPv4 P2P user information control block, TP and AP.  Figure 4.2B shows the new IPv6 header block.  Notice that both Network Protocols (router intercommunications) and Transport Protocols encapsulating the Application Protocols are now part of the IPv6 Data Block placed just after the IPv6 Header.

IPv4_NP_Block
Figure 4.2  IPv4 Network Router Request

IPv4_TP_AP_Block
Figure 4.2A  IPv4 Datagram Transport Block

IPv6_Transport_Block
 Figure 4.2B  IPv6 Header Block

An IP header is required for any network scheme, what makes them unique is the information or fields within the headers.  Both IPv4 and IPv6 schemes, the IP Address Header identifies the source and destination addresses, where they become different is that IPv4 header identifies the NP (Network Protocol ), TP (Transport Protocol) and AP (Application Protocol).  For IPv6 the NP, TP and AP blocks are now located in the data block following the header and are identified within that block through out the network path.  Remember that regardless of the scheme they all must contain the protocols to carry user data P2P.

The Transport Protocol selected is the container that the Application Protocol will be placed in for transport. Tranport Protocols must also be recognized by the network routers transporting the data, else the data is just dumped and transmision is terminated.  Many of the NP communications are transparent to the end users and are primarily used to insure the QoS (Quality of Service) for the overall  network.  These NP's handle many transparent functions such as DNS (Domain Name Service) servers that have the ICANN domain names to IP addresses, ISP (Internet Service Provider) routers to your local router at the end users connection.  The Internet (Information Highway) is just the transport agent as any transportation highway and require some fixed rules.  What makes this transport agent work are the interconnecting routers and servers specific communications with fixed Network Protocols, hence, "protocols are the heart of the Internet".

Figure 4.3 shows the IPv4 header, RFC791 and Figure 4.4 show IPv6 header, RFC2460, as we see they are displayed in 32 bit format, grouped in Octet (8 bit) format.  The reason for this format is based more on the 8 bit octet for NIC (Network Interface Controller) hardware to guarantee a fixed byte protocol compatibility standard.  Reading a block of data in byte form at high speeds allows for better data integrity and less skewing. Every desktop, Laptop, Smartphone, Tablet etc incorporates a NIC of some sort that complies with the software protocol formats.  This is what allows the Internet to function as efficiently as it does.  There is no magic in any of this, just pure logic and technical book keeping of the different protocol processes.  

IPv4 has more information in the header that identifies the attached data packet.  The type of IP header and block NP or TP depends on the type of payload, a network protocol or an application protocol.  Again all that is required to transport data P2P is to follow the Network Protocols and the Transport Protocols, both are required by the Internet routers to insure the transport of the Application Protocol P2P is completed.  The end nodes require that the Application Protocols are matched in order to encode/decode the data being transported.

There is only one difference between the Internet header bit assignments and the standard computer technology bit assignments, that is the identification of the LSB (Least Significant Bit); in the computer world the LSB is bit 0 is weighted right to left MSB…LSB to coincide with the 20 =1 weighting binary representation of the decimal numbering system.  In the Internet headers and serial bit streaming digital world most serial communications send the MSB (Most Significant Bit) first and the LSB last which is why the nomenclature is reversed.  When we get into the core hardware design this MSB-LSB difference will be continued.

IPv4_Header
Figure 4.3  IPv4 Header Block

IPv6_Header
 Figure 4.4  IPv6 Header Block

IPv4 Header Fields:
Table 4.2 below shows the header fields for IPv4 and 4.3 shows the header fields for IPv6.  The smallest IPv4 header is 20 octets (00-19) with options upto 36 octets.  The IPv6 header is fixed at 40 octets and any further information is attached to the data area following the header.  Like all designs that evolve IPv4 was the first of its kind and as an engineer and designer the first thoughts of what it should to is "Everything" that a network should do!  OK, and what is "Everything"?  The answer for IPv4 is all those different fields in the header, the answer for IPv6 is the same but with less fields and a different organizational methodology for the protocols that allow for the experiment of different schemes since the header is fixed.  Remember all that has to occur to run a different scheme is to add additional firmware to the Network Protocol part of the routers on the Internet.  There are provisions to select the path through some customized routers that experiment with the next generation of Internet schemes.  Keep in mind that IPv6 has all the functionality of IPv4 with some improvements and added functionality for controlled communications.  With IPv6 the data after the header is identified in the "Payload Length" field parameter of the data attached.  All protocols incorporated are in the data attached this includes inter router Network Protocol communications.  The three protocol areas still must hold in order to be compliant with the OSI model, the only difference is where they are defined in the data block.  The P2P IP addresses are always placed in the IP header regardless of the scheme.  This is to insure that the P2P addresses are expected to have the same protocols used for encoding/decoding.  Which enforces the fact that IPv4 and IPv6 are just schemes to transport data and the Network Protocols inter router communications are the highway signs to direct the data to the destination node.

Decoding The Header Fields:
The first 4 bits (Version) of the header are used to identify the IP scheme version, this is how the Internet separates the type of  Internet Protocol schemes.  These 4 bits allow room for up to 15 different IP schemes as shown below.  This is how the schemes are separated and redirected to the software protocol decoding that applies to the scheme. A different scheme would require the update of the routers and servers on the Internet to accommodate the new scheme, for this series we will focus on IPv4 and IPv6.  As we see IPv4 and IPv6 headers are very different in how they are processed and to date there are many more IPv4 devices being used than IPv6 devices at the users level.  We will present both schemes in order to effectively develop our core IoT platform to function on both systems seamlessly.

The Version field in the header Bits 0-3 of Octet 00, (00-15 decimal), 0000-1111 binary, MSB…LSB identifies the IP scheme version.  There are other experimental protocol version being developed, the RFC (Request For Comments) numbers are associated with these protocols in the table, the Version table is defined in RFC1700.  By putting the IP version type in the first Octet bits 0-3 many different schemes may be used for the same transport mechanism.  The main requirement is that any protocols used for the scheme are expected to be identified and capable of encoding/decoding the data at each node.  The streamlining of the IPv6 header easily allows for new schemes to be developed as long as the inter router communications are able to identify and apply the new protocol schemes, if not the data is just dropped and the transmission ends at that point.

Many of the IPv4 fields are moved to the data area in IPv6, the requirements are still there just move for convenience and efficiency.  The largest section in the table is the protocol field of the IPv4 header which is set at the end and is also is the one we will be concerned with mostly for out core IoT platform.  The IPv4 Header is generally part of the TCP/IP Internet Suite and there are many third party libraries available to implement into a custom device development.  The TCP/IP Internet Suite is also designed into many operating system platforms like Linux®, BSD® Unix, Windows®, MAC OSx® and others.

Name Bits (Size) Octet # RFC Number Description
Version 0-3
(4 bits)
0

RFC1700

Internet Protocol header Version 4 bits, IPv4 = 4

Version Description Version Description
0
(0000)

Reserved

8
(1000)

PIP  P Internet Protocol  RFC1621 - RFC1622

1
(0001)

Unassigned

9
(1001)

TUBA  TCP+UDP+Big Address RFC1561

2
(0010)

Unassigned

10
(1010)

Unassigned

3
(0011)

Unassigned

11
(1011)

Unassigned

4
(0100)

IPv4 Internet Protocol RFC791

12
(1100)

Unassigned

5
(0101)

ST  ST Datagram Model RFC1819

13
(1101)

Unassigned

6
(0110)

IPv6 Simple Internet Protocol  RFC2460

14
(1110)

Unassigned

7
(0111)

TP/IPC  Next Version Internet  RFC1475

15
(1111)

Reserved

Name Bits (Size) Octet # RFC Number Description
IHL 4-7
(4 Bits)
0  

Internet header Length 4 bits. This is the IP Packet header word in 32 bit format. The minimum value for this is 5. The Option Octets 20-31 will add to this number.

ECN 14-15
(2 Bits)
1

RFC3168

Explicit Congestion Notification - Used for point to point packet loss, used with VPN tunnels.  All points along the way have to include this feature in order to function.   ECN=00-Not ECT, 01-ECT(1), 10-(ECT(0), 11-CE

Total Length 16-31
(16 Bits)
2-3  

This is the total length of the payload/packet size - The header size in not part of this number.  The max length is 65535 (16 bits)

Identification 32-47
(16 Bits)
4-5 RFC6864

The 16 bit IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol.

Fragment Offset 19-31
(13 Bits)
6-7

RFC791
RFC815

In the routing of messages from one Internet module to another, datagrams may need to traverse a network whose maximum packet size is smaller than the size of the datagram.  To overcome this difficulty, a fragmentation mechanism is provided in the Internet protocol.  RFC791 explains fragmentation and RFC815 explains the recombining of the fragments process.

Time To Live 0-7
(8 Bits)
8  

An eight-bit time to live field helps prevent datagrams from persisting (e.g. going in circles) on an Internet. This field limits a datagram's lifetime. It is specified in seconds, but time intervals less than 1 second are rounded up to 1.   In practice, the field has become a hop count - when the datagram arrives at a router, the router decrements the TTL field by one. When the TTL field hits zero, the router discards the packet and typically sends an ICMP Time Exceeded message to the sender. The program trace route uses these ICMPvX Time Exceeded messages to print the routers used by packets to go from the source to the destination.

Header Checksum 16-31
(16 Bits)
10-11 RFC1071

The Header Checksum has several updates RFC1141  to RFC1624  It is the checksum of the header only that is calculated by the router during transmission. The payload checksum is not calculated in order to reduce the time to transport.

Source IP Address 0-31
(32 Bits)
12-15  

This is the full 32 bit source IP address - the sender

Destination IP Address 0-31
(32 Bits)
16-19  

This is the full 32 bit IP address of the destination - the receiver

Options (IHL>5) 0-31
(128 Bits)
20-35  

 

ECN 14-15
(2 Bits)
1

RFC3168

Explicit Congestion Notification - Used for point to point packet loss, used with VPN tunnels.  All points along the way has to include this feature in order to function used for point to point packet loss, used with VPN tunnels.  All points along the way have to include this feature in order to function.  ECN = 00-Not ECT, 01-ECT(1), 10-(ECT(0), 11-CE

DSCP 8-13
(6 Bits)
1

RFC2474 
RFC2597

Differential Services Code Point - This is used for protocols like VoIP, Media etc -   RFC3265 Session Initiation Protocol.  Other RFC that apply   RFC5865   RFC2598   RFC3246
The RECOMMENDED values of the CS (Class Selector)  and AF (Assured Forwarding) codepoints are as follows.

DS CodePoint Description DS CodePoint Description DS CodePoint Description
0   (000000) Class Selector 0 - RFC2474 10 (001010) Assured Forwarding 11 - RFC2597 10 (001010) Assured Forwarding 33 - RFC2597
8   (001000)

Class Selector 1 - RFC2474

12 (001100) Assured Forwarding 12 - RFC2597

34 (100010)

Assured Forwarding 41 - RFC2597
16 (010000)

Class Selector 2 - RFC2474

14 (001110) Assured Forwarding 13 - RFC2597

36 (100100)

Assured Forwarding 42 - RFC2597
24 (011000)

Class Selector 3 - RFC2474

18 (010010)

Assured Forwarding 21 - RFC2597

38 (100110)

Assured Forwarding 43 - RFC2597
32 (100000)

Class Selector 4 - RFC2474

20 (010100)

Assured Forwarding 22 - RFC2597

44 (101100)

Capacity Admit'd Traffic - RFC5865
40 (101000)

Class Selector 5 - RFC2474

24 (010110)

Assured Forwarding 23 - RFC2597

46 101110

Expedited Forwarding PHB - RFC3246
48 (110000)

Class Selector 6 - RFC2474

26 (011010)

Assured Forwarding 31 - RFC2597    
64 (111000)

Class Selector 7 - RFC2474

38 (011100)

Assured Forwarding 32 - RFC2597    
Flags 16-18
(3 Bits)
6  

Fragment Identification Status    
Bit-18 MF  =1  Do Not Fragment - used with PMTUD (Path MTU Discovery) RFC191
Bit-17 DF = 1 More Fragments in route - in the last packet this bit is set to 0
Bit-16 R =Reserved=0

R-16 DF-17 MF-18 Description
0 1   Fragmentation required to route the packet the packet is dropped
0 0   Do Not Fragment - used with PMTUD (Path MTU Discovery) RFC191
0   1 More Fragments in route - in the last packet this bit is set to 0
0   0 No More Fragments in route   R=Reserved=0

The protocol field identifies the different Transport Protocols (TP) available.
The protocols highlighted are the ones we will be addressing for the core IoT platform development.

Protocol 8-15
(8 Bits)
9  

The following is the latest Internet Protocol IANA assigned numbers, RFC1700, along with the latest reference RFC# document.  Each RFC will have a back trace to the original RFC from the original release.  There are a lot of protocols that have evolved over the years and I am sure this list will be upgraded many more times. The IPv4 only allows for 254 protocols however IPv6 the protocol is defined in the following header.  A full list of the IANA protocol registry from A to Z.  These Protocol Number ID's are not the same as the Port Protocol ID's.  These are the transport protocols that encapsulate the application protocol and data and used to direct the datagram/packet to its destination IP address.

Protocol ID

Acronym

  8 Bits, [ Bits 8-15, Octet 9 ]  Protocol Description  -  RFC References

0

 

Reserved

1

ICMP

Internet Control Message Protocol  - RFC792

2

IGMP

Internet Group Management Protocol  RFC3376

3

GGP

DARPA Internet Gateway-to-Gateway  -  RFC823

4

IP

IP in IP (encapsulation)  RFC2003   

5

ST

Stream - RFC1819, IEN119

6

TCP

Transmission Control - RFC793 Update RFC3168, RFC6093, RFC6528

7

UCL

UCL

8

EGP

Exterior Gateway Protocol - RFC904

9

IGP

Any private interior gateway

10

BBN-RCC-MON

BBN RCC Monitoring

11

NVP-II

Network Voice Protocol - RFC741

12

PUP

PUP - PUP,XEROX

13

ARGUS

ARGUS

14

EMCON

EMCON

15

XNET

Cross Net Debugger

16

CHAOS

Chaos

17

UDP

User Datagram - RFC768

18

MUX

Multiplexing

19

DCN-MEAS

DCN Measurement Subsystems

20

HMP

Host Monitoring - RFC869

21

PRM

Packet Radio Measurement

22

XNS-IDP

XEROX NS

23

TRUNK-1

Trunk-1

24

TRUNK-2

Trunk-2

25

LEAF-1

Leaf-1

26

LEAF-2

Leaf-2

27

RDP

Reliable Data Protocol - RFC1151

28

IRTP

Internet Reliable Transaction - RFC938

29

ISO-TP4

ISO Transport Protocol Class 4 - RFC905

30

NETBLT

Bulk Data Transfer Protocol - RFC998

32

MFE-NSP

MFE Network Services Protocol

32

MERIT-INP

MERIT Internodal Protocol

33

SEP

Sequential Exchange Protocol

34

3PC

Third Party Connect Protocol

35

IDPR

Inter-Domain Policy Routing Protocol

36

XTP

XTP

37

DDP

Datagram Delivery Protocol

38

IDPR-CMTP

IDPR Control Message Transport Protocol

39

TP++

TP++ Transport Protocol

40

IL

IL Transport Protocol

41

SIP

Simple Internet Protocol

42

SDRP

Source Demand Routing Protocol

43

SIP-SR

SIP Source Route

44

SIP-FRAG

SIP Fragment

45

IDRP

Inter-Domain Routing Protocol

46

RSVP

Reservation Protocol

47

GRE

General Routing Encapsulation

48

MHRP

Mobile Host Routing Protocol

49

BNA

BNA

50

SIPP-ESP

SIPP Encap Security Payload

51

SIPP-AH

SIPP Authentication Header

52

I-NLSP

Integrated Net Layer Security TUBA

53

SWIPE

IP with Encryption

54

NHRP

NBMA Next Hop Resolution Protocol

55-60

 

Unassigned

61

 

Any host internal protocol

62

CFTP

CFTP

63

 

Any local network

64

SAT-EXPAK

SATNET and Backroom EXPAK

65

KRYPTOLAN

Kryptolan

66

RVD

MIT Remote Virtual Disk Protocol

67

IPPC

Internet Pluribus Packet Core

68

 

Any distributed file system

69

SAT-MON

SATNET Monitoring

70

VISA

VISA Protocol

71

IPCV

Internet Packet Core Utility

72

CPNX

Computer Protocol Network Executive

73

CPHB

Computer Protocol Heart Beat

74

WSN

Wang Span Network

75

PVP

Packet Video Protocol

76

BR-SAT-MON

Backroom SATNET Monitoring

77

SUN-ND

SUN ND PROTOCOL-Temporary

78

WB-MON

WIDEBAND Monitoring

79

WB-EXPAK

WIDEBAND EXPAK

80

ISO-IP

ISO Internet Protocol

81

VMTP

VMTP

82

SECURE-VMTP

SECURE-VMTP

83

VINES

VINES

84

TTP

TTP

85

NSFNET-IGP

NSFNET-IGP

86

DGP

Dissimilar Gateway Protocol

87

TCF

TCF

88

IGRP

IGRP - [CISCO]

89

OSPFIGP

OSPFIGP - RFC1583

90

Sprite-RPC

Sprite RPC Protocol - [SPRITE]

91

LARP

Locus Address Resolution Protocol

92

MTP

Multicast Transport Protocol

93

AX.25

AX.25 Frames

94

IPIP

IP-within-IP Encapsulation Protocol

95

MICP

Mobile Internetworking Control Protocol

96

SCC-SP

Semaphore Communications Sec. Protocol

97

ETHERIP

Ethernet-within-IP Encapsulation

98

ENCAP

Encapsulation Header - RFC1241

99

 

Any private encryption scheme

100

GMTP

GMTP

101-254

 

Unassigned

255

 

RESERVED

Table 4.2  IPv4 Header - Field Names and Description

IPv6 Header Fields:
The IPv6 transport block is just rearranged with a few added protocols and functions.  The Network Protocols, Transport Protocols and the Application Protocols are attached to the IPv6 header and called the data area.

References:
Network Sorcery:  http://www.networksorcery.com/enp/topic/ipsuite.htm
The Internet Engineering task Force:  IETF - RFC references

Name Bits (Size) Octet # RFC Number Description
Version 00-03
(4 bits)
0

 

Internet Protocol header Version 4 bits, IPv6 = 6

Traffic Class 04-11
(8 bits)
0, 1 RFC2460

Traffic Class - Same as DSCP+ECN in IPv4 - The 8-bit Traffic Class field in the IPv6 header is available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets.  At the point in time at which this specification is being written, there are a number of experiments underway in the use of the IPv4 Type of Service and/or Precedence bits to provide various forms of "differentiated service" for IP packets, other than through the use of explicit flow set-up.  The Traffic Class field in the IPv6 header is intended to allow similar functionality to be supported in IPv6.

Flow Label 12-31
(20 bits)
1,2,3 RFC3593

Several standards-track MIB modules have defined objects to represent an IPv6 Flow Label (sometimes referred to as Flow ID) [RFC2460] and IPv6 Flow Label filters.  Unfortunately the result is a set of different definitions for the same piece of management information.  This may lead to confusion and unnecessary complexity.  This document defines a set of textual conventions (TCs) that can and should be (re-)used in MIB modules, so that they all represent an IPv6 Flow Label in the same way.  In fact, PIB modules can and should also use these TCs when they need to represent an IPv6 Flow label.

Payload Length 00-15
(16 bits)
4, 5 RFC2675

This is the total length of the payload/packet size - The header size in not part of this number for payloads under 16 bits. For payloads over 16 bits it is a Jumbo payload and the header is added to the full payload size.  The max length is 65535 (16 bits)

Next Header

16-23
(8 bits)

6  

This field is similar to the Protocol field in IPv4 and defines the next header type. The two most common are TCP(6) and UPD(17). The next header starts at the end of the IPv6 header at octet 40.  The protocol requirements for the transport and applications are now moved to the end of the IPv6 header.

Hop Limit 24-31
(8 bits)
7  

This is a Time To Live limit to the number of hops to get to the next or final destination address.  At each router this number is decreased by 1 until the hop limit reaches zero, at which time the transport block is deleted if it is not the destination.

Source Address 00-31
(128 bits)
8-23  

This is the full 128 bit source IP address - the sender

Destination Address 00-31
(128 bits)
24-39  

This is the full 128 bit IP address of the destination - the receiver

Table 4.3  IPv6 Header - Field Names and Description

Protocols and Ports Classification: Single IP Address Many Ports and Protocols
There are many Application Layer protocols, a full list of the IANA protocol registry from A to Z, that may be applied to the core IoT platform device, however we will pick the main ones we want to control the device with at this time with the intention of easily adding AP's at a later date.  Each layer in the OSI model's four groups have a set of assigned protocols that configure/format the data  that is presented to the TCP/IP OSI model.

Back in Part 3, Figure 3.0 we presented the fact that each IP address has 65,535 ports that the data may pass through, well this is where we use those ports.  Only one IP address is handled at a time and is sent through the TCP/IP OSI layers, it just happens so fast it looks like many IP addresses pass through all at once.  What happens is that one IP address may service many functions serially in a time shared/sliced methodology.  This is like when you download a file from the Internet using FTP (File Transfer Protocol) in one browser window and open another browser window and start browsing the Internet while you are downloading the file, you are connected using only one IP address and browsing and downloading from many, however, it is time shared and only one source/destination pair of addresses happen at a time slice.  The OSI Layers Identified the application as HTTP and FTP protocols and separate the two specific sessions that keep the source-destination IP addresses along with other session parameters and routes the data accordingly, one to the display and the other to a file on the disk.  The Internet "Information Highway" is only the transport mechanism, while the TCP/IP OSI layers identify the data characteristics to be transferred, source-destination, I know I said that many times before, a bit of a nag? well, repetitiveness is the mother of retention.  At this point we consider the protocols to be IP address port application protocols and are defined in the IANA port assignments.  Socratic methodology applied to product design allows us to question the final results desired, then question each preceding stage working back to the initial stimulus in order that each stage will have the stimulus capability for the following stage and so on until we obtain the final results we desire as shown in Figure 4.0 Internet Data Flow P2P.

To start we will list the IP address port protocols with there description and decide if this protocol should be added to the core IoT Platform.  Once we decide the application port protocols we will discuss these protocols, their format and configuration and how it will flow through the core IoT Platform end to end.  Table 4.4 lists the Application Layer group IP address port protocols along with the core features of our IoT Platform.

Protocol Communication Protocols Description Port ID

Core IoT Platform   Feature Description

IoT Platform
HTTP

HyperText Transfer Protocol - A markup language used for Web communications

80

Allows the IoT Platform to communicate through a web browser - Configure and setup the IoT device through a web browser

YES
Telnet

A text oriented bi-directional data communications using virtual terminal connection, 8 bit, byte connection

23

Allow simple text  communications over the Internet.  Use for debugging and troubleshooting - requires security policies.

YES
SMTP

Simple Mail Transfer Protocol  - Standard for E-Mail transmission over the Internet

25

Allow E-mail to be transmitter from the IoT Device - E-mail controller on status or errors - requires security policies.

YES
FTP

File Transfer Protocol - A client-Server based protocol to transfer data files over the Internet.

21

Allows the IoT platform to transfer datafiles - - requires security policies.

YES
NTP

Network Time Protocol - Networking protocol to synchronize time between computer systems

123

Allow the synchronization of timed events of multiple IoT devices

YES

Table 4.4  TCP/IP OSI Model
Communication Protocols for Core IoT Platform

From the above table of protocols the features incorporated into the core IoT platform will allow communications over the Internet using a standard web browser, transfer data files through FTP, synchronize the time for many IoT platform devices to act together in a synchronous manor, send emails to a server on the status of the IoT platform devices and connect with a basic text terminal to IoT Platform devices through the Telnet protocol.

Now that we have this list created lets put it in a safe place for now, we will get back to this when we are in the platform design section of the series.  Lets get back to the Internet Protocols presentation.  There are other protocols that are unique in which IANA assigned a specific IP Address and fall into a Network Protocol information class.   These protocols have a specific datagram/payload or packet header formats.  Table 4.5 lists the device communications class of protocols and Table 4.6 list the special multicast protocol that also are assigned specific IP address port assignments.

Protocol Communication Protocols  Description Port ID Feature Description IoT Platform
Unicast

Single end to end data packet transfer - Address = Point to Point  IP addresses

 

IPv4 IPv6

 
Broadcast

Single to Many data packet transfer - Address = Block of Subnet LAN Addresses

 

IPv4 LAN

 
Anycast

Single to Many within Subnet Group - Address = Block of Routers Subnet Addresses

 

IPv6

 

Table 4.5  Internet Protocols
Global Protocols for Status, Configuration & Payloads

A little bit of history on why these protocols were created. In the beginning release of  IPv4 the two of the main communication class protocols were Unicast and Broadcast; these were fine until streaming video came along and started to bottleneck the Internet bandwidth, we will show this next.  The solution that emerged was a new protocol class labeled Multicast which incorporated a series of new IP address port assigned protocols.  The Multicast protocol did change for IPv6 by transfering of some of the IPv4 Broadcast protocol functions into IPv6 Multicast protocol.  With the changeover to IPv6 a new protocol called Anycast was introduced to handle the remaining IPv4 Broadcast protocols to eliminate Broadcast altogether in IPv6.  This now brings us to the dual mode core IoT platform that will seamlessly handle IPv4 and IPv6 schemes.  The protocols in Tables 4.5 and 4.6 are a special class because they have pre-assigned IP Address by IANA and are masked to act on a block of IP addresses assigned to devices.  These protocols have unique IP headers assigned to them which we will cover in another part of the series.   Ok, lets look at some pictures to explain the overall data flow of these new protocols. Figure 4.5 through 4.8 show overviews of how each of these protocols handle the data transfer.  The detailed presentation of these protocols will follow in the next part of the series, for now it is important to keep in mind the high level concept of these protocols.  Once again, every protocol must have a source-starting point or command execute point and a destination -response, configure, control point.

Multicast Communication Protocols  Description Port ID Feature Description IoT Platform
MSDP

Multicast Source Discovery Protocol RFC3618

639

IPv6

 
MADCAP

Multicast Address Dynamic Client Allocation Protocol

2535

IPv4

 
mDNS

Multicast Domain Name System

5353

IPv4

 
LLMNR

Link-Local Multicast Name Resolution

5355

IPv6

 

Table 4.6  Internet Protocols
Multicast Protocol Port Assignments

 

IPv6, IPv4 Unicast: high level Overview
The Unicast is the easiest to understand since it is a single point to point data transport - single source - single destination. The 5 Megabits per second connection is just a standard cable connection, DSL would be 1 Megabits per second typical.

Unicast_on
Figure 4.5 Unicast Single Source, Single Transmission to Single Destinations

IPv6, IPv4 Multicast: High Level Overview
A bit confusing without a picture, Consider this scenario, you are the software protocol, very flexible, able to perform unlimited sequences and connect globally to transfer information, easy, use your smart phone as a resource.  Oh, what?, you don't know the phone number but you do have a name and state, no problem, just search the Internet for the names in the state, you are now acting as the host and you send out a Multicast request to Search the Internet (Google® it); the response is a block of phone numbers that match the name and state, wow, too many names. OK you want to narrow the search, so you do another Multicast request with a narrower field like state and city, still the same multicast protocol with just more bits set to 1 in the Multicast IP address.  OK the response is the actual phone number you are looking for. So what we did was send out A Multicast Request to everyone to give us the phone number that fits a certain criteria and we received a single phone number.   Next is to call the number, then the destination phone rings, you are sending a Unicast datagram to ring the phone, this requires that the sending protocol is able to be received by the destination hardware and be aware of the actual phone number being sent, this is the first part of the physical (synchronous) handshake.  Now the destination phone is answered and this completes the physical (synchronous) handshake.  OK the phone at the destination is answered and you send the data hence, the header and protocol information along with the information data, remember that from part 3?.  Keep this simple process in mind that all protocols must have a source-destination, (stimulus-response) and we will be able to build on this concept with clarity as we present the protocols we need to design our IoT core platform hardware.

To review history, just a little, IPv4 was in a continuous state of review and upgrades since it was the first scheme of its class to come along that had a standard global future.  It went from a few hundred in 1978 to over 1.5 Billion in less than 25 years.  IPv6 is 20 years old in January,2016 and since its' release it has addressed and eliminated many of the IPv4 limitations, however, there is a cost for this change.  The change came in the protocol classes and how they function, since we now have to contend with both IPv4 and IPv6 schemes.  IPv4 relied on the Broadcast protocol to handle many of the broad device requests on the LAN.  IPv6 has eliminated the Broadcast protocol and replaced it with Anycast also took some of the Broadcast protocols and carried them over to the Multicast protocol in order to organize its scope to the current IPv6 subnet it is executed on.  Remember there is nothing magical about any of the class protocols, they may originate from routers, Operating Systems, or Devices, it still has a stimulus-response methodology.  Figure 4.6 shows the sender sending the same information five times to five separate users which takes a longer time to send.  This is similar to the bottleneck in the routers using only one IP to send/receive to many users, this is always a time-slice process where the time is shared by the number of users so the bandwidth decreases is defined by, Throughput = Total Bandwidth ÷ Number of users.

Multicast_off
Figure 4.6  Single Source, Single Transmission to each destination separately

Figure 4.7 shows the same data stream but under a multicast send process.  The sender only sends the transmission to the server once and the server only sends it to the each one of the multiple users at the same time only once. It is easy to see why Multicast is used for streaming data, Multicast conserves on bandwidth by masking a block of IP addresses in multiple subnets and only has to send the data stream once.  The Multicast protocol handles the global Internet Subnet to Subnet.  This is just like texting or e-mailing multiple users one way anywhere in the world.  Without Multicast the server would be sending out the same data to each individual as fast as it could, this requires N times the bandwidth since it is sending out multiple P2P streams which consumes server bandwidth.  Other type of IPv6 Multicast functions are also available to locate who is on the network,  MLD (Multicast Listener Device) mask, this woudl work both on the ULA private network or the subnet global as well.  For IPv4 LAN you would perform and ARP request, returned would be a list of devices with their MAC address that are on the LAN.  

The Multicast protocol is used for web broadcasts (webinars) and is sent out to each user registered to the subnet.  If the users misses the webinar that router just dumps the data while the remaining connections view the webinar.  This does not fix all the streaming issues however it is a great start.

Multicast_on
Figure 4.7   Multicast Single Source, Single Transmission to Multiple Destinations

IPv6 Anycast: high level Overview
This is a new class type protocol and it is used very similar to Multicast except that the destination IP addresses are in a single Subnet.  Anycast address protocol is still in its experimental mode and I would guess that until there is a better understanding of Internet Protocols and the time and path responses for the protocol it will be seldom used.  Anycast addressing would be difficult and burden routers if sending to multiple subnets globally, Anycast attempts to find the shortest path to the destination. Anycast would be more efficient kept on the same IPv6 subnet.

Anycast_on
Figure 4.8 Anycast Single Source, Single Transmission to Local Subnet Multiple Destinations


Reference Links:
The majority of Internet scheme and protocol information are from a few open public information sources on the net, the IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet and the Network Sorcery web site. The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) series presentations and follows the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery:  http://www.networksorcery.com
The Internet Engineering task Force:  IETF - RFC references
Wikipedia https://en.wikipedia.org/wiki/Main_Page

Part 5 will cover - How protocols interact with the Internet, Selected protocol details, the Transport block from point to point, The Unicast, Multicast protocols assigned IP addresses and expected responses from them, Typical TCP point to point.


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) - Security, Privacy, Safety - The Information Plaground Part 4: IPv4, IPv6, Protocols, Network, Transport & Application: (January 10, 2017)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=9&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) - Security, Privacy, Safety - Platform Development Project  Part-4  IPv4, IPv6, Protocols, Network, Transport & Application (January 10, 2017)</p>

 

Sal_Tuzzo

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

 

Welcome to the BASIL Networks Public Blog

administration | 10 January, 2017 07:24

We are looking forward to many great publications that will contribute to the industry in fhe areas of New Technology Product Development, IoT Product Design and Development, Internet Security, Hardware and Softwware and many other topics.

There are a few General blog etiquette rules for posting on this site, please review at your convenience.

If you would like to publish your articles on this board just drop us a line on our contact form and tell us what you have in mind.

 

Enjoy the blog
The Basil Networks Team

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-3

saltuzzo | 24 November, 2016 09:26

Part 3: IPv4, IPv6, DHCP, SLAAC and Private Networks:
The Automatic Assignment of IP Internet Addressing

In all chaos there is a cosmos, in all disorder a secret order - Carl Jung

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 & IPv6
- The Ins and Outs of IP Internet Addressing (November 11, 2016)
Part 4 IPv4 & IPv6 Protocols
- Network, Transport & Application (January 10, 2017)
Part 5 IPv4 & IPv6 Protocols - Continued - Network, Transport & Application  (Aug 17, 2017)
Part 6 IPv4 & IPv6 Protocols - Network, Transport & Application Continued (Sept 24, 2017) 

Lets Get Started: Quick Review to Set the Atmosphere for Part 3
From Part-2 we discussed the simple side of the two IP addressing schemes that are easily understood in this new "Information Highway" era.  It is easy to see how we can trace a physical address location from point A to point B with a simple numerical addressing scheme.  Also In Part-2 for simplicity we used Class A, B, C, D for the point to point directions.  In reality IPv4 classes have been frowned upon since the 80''s following the release of RFC-1519 CIDR (Class Inter-Domain Routing) in 1993 and with the creation of  IPv6 the new scheme is considered a classless scheme.  Instead of classes IPv6 is identified by a Global ID and SubNet ID assigned to a Interface Device ID or EUI.  This part of the series we will go one step further to characterized the IP address and associate it with a unique physical identifier for the source and destination IP addresses.  Before we get deeper into network technology it would be easier to look at the IP address as a point to point direction with the ability at the to funnel data through 1 to 65535 doors, rooms better yet ports as shown in Figure 3.0.  IP address ports have been categorized for specific types of data transfers like Port 80 is primarily used with your Internet browser and sends/receives data through port 80 of the IP address.  We presented ports lightly in part-2, the complete list of port assignments can be found at Ports.  This will be addressed in more detail in the Security and hardware design of the series.


  Figure 3.0   IP Address Available Ports

When we look at a network and all the different types of devices connected with all the different software applications that transport data over the network, it is reasonable to try and categorize devices and software applications by protocol where the IP scheme is defined as a transport agent for these communications protocols, this is true for both IPv4 and IPv6.  We will briefly introduce a few of these communication protocols used in order to get a better understanding how hardware and software coincide, the protocols we will introduce are Unicast,  Multicast and Broadcast.  Unicast type protocol as it appears is a single host sending to single host receiving data packets.  Multicast protocol is a protocol  that allows a single device to communicate with specific hosts and devices on a network, hence from one or many selected addresses or many selected to many other selected addresses.  Broadcast protocol is sending packets from a single device to many other devices on a network, all hosts on a single subnet and/or all subnet's.  This will be covered in the security and software design section of this series.  There are many other protocol type requests that are part of the previously mentioned and some of them we will cover in this part.  The intent is to accumulated the required network understanding relate to the design of the core platform IoT hardware, firmware and software.

So, now that we are able to get from point A to Point B and we are standing in from of the house and it would be nice to identify the actual house uniquely that makes it different from all the other houses.  Relating this to the IP address the house will be assigned another identifying characteristic, say the builders name and the builders type of house and the number built to date.  In network terms this is call the  MAC (Media Access Control) address, great another acronym.  IPv4 and IPv6 address is a scheme or direction to get from Point A to Point B while the MAC address is the PII (Personal Identifiable Information) of the house.  In computer terms the MAC is the Machine ID that is unique to every device connected to the Internet.  To start with the right terminology the MAC acronym has bee formally changed to EUI  (Extended Unique Identifier), OK, yet another acronym to keep track of.

Some basic IP masking terminology to keep in mind.  Many times in the networking environment you will notice an IP address line 192.168.1.0/8 where the /8 is the number of bits to mask as part of the absolute address.  This relates to the IP address of 192.168.001.0 and a mask of 255.255.255.000.  So the total 32 bit address would be 192.168.001.xxx, where xxx is the users devices address between 0 - 255 addresses.  In bit form the mask would be 11111111.11111111.11111111.00000000.  The 1's indicate the absolute part of the address, 192.168.1.  The /#bits always starts at the high end (left to right) of the address for both IPv4 and IPv6.  Lets summarize some of the acronyms we have,  Table 1.0 lists the new acronyms used with the IP schemes so far, by the way, the Internet Technology arena has an acronym for everything as we will see.

Acronym Name Description  - Stands For Protocol
WAN Wide Area Network IPv4 and IPv6
LAN Local Area Network IPv4
ULA Unique Local Address- Private Network IPv6
NAT Network Address Translation IPv4
P2P Pear to Pear or Point to Point IPv4 and IPv6
MAC Media Access Control IPv4 and IPv6
EUI Extended Unique Identifier (label change from MAC) Ipv6
IP Port IP has 65535 Ports IPv4 and IPv6

Table 3.0   Review of Some Basic IP Acronyms

MAC (Media Access Control), EUI (Extended Unique Identifier) address:
Ins & Outs of a Device/Access Control Identifiers

Before we get into the IPv6 technical details we have to cover some information about all devices attached to the Internet.  We discussed IPv4 and IPv6 addressing schemes which are just different addressing schemes, directions P2P only.  The MAC address is a "hardware identification" address, has been formally renamed to EUI (Extended Unique Identifier)  to conform with IPv6.  The EUI is not just the destination point IP address scheme used as directions between two points but a unique hardware address ID that separates it from all other hardware.  All devices connected to the Internet are required to have a MAC/EUI address.  The MAC-48/EUI-48 address is a 48 bit physical hardware address, (248 = 281,474,976,710,656 possible addresses), that is part of the NIC (Network Interface Controller) that is assigned by the manufacture of the controller and is supposed to be unique.  All smart phones, computers, tablets, any device that is connected to the Internet has a MAC/EUI address.  NIC manufactures request a block of  addresses at IEEE for their devices each address of the 24 bit block it is used only once.  The 48 bit EUI-48 address format as shown in Figure 3.1 and is split into two 24 bit blocks, the first 24 bit block is the unique Company/Manufacturer ID and the second 24 bit block is the unique physical hardware ID.  The EUI-48 address is considered a permanent burnt in address for the hardware and are handled differently between the two IP schemes as we will see.  The 24 bit blocks indicate that there allowed 16,777,216 manufacturers and each manufacturer may manufacture 16,777,216 controllers.  With IPv6 addressing we have 340x1036 addresses available which means that we will run out of EUI-48 addresses at some future date and considering IoT devices and the huge market it may be sooner than later.  Granted many NICs are now in the trash and out of circulation this will just prolong the inevitable.  We will see why this is important when we discuss IPv6 and the EUI-48 and EUI-64.  Although the EUI-48 address is considered permanent, with today's technology there are ways to change your EUI address, for now lets consider it permanent.  We will get into changing EUI-48 and EUI-64 in the security part of the series, at this point we are still addressing understanding the characteristics or modes of the IP schemes.


Figure 3.1 MAC-48 Now Called EUI-48 Address Format

In IPv4 the EUI-48 address is kept local to the actual computer or devices on the private network LAN, the IPv4 router does not route the EUI across WAN Internet, therefore it is possible to have duplicate EUI addresses in two different global IP address locations LAN since the EUI for IPv4 LANs never gets to the Global Internet.  There are a minimum times when the EUI is collected in an Server-Client application, however the possibility of duplicate EUI-48 addresses in a P2P application is not likely to happen.  The EUI-48 may be obtained on any device address in an IPv4 LAN locally by the devices OS (Operating System) issuing an ARP (Address Resolution Protocol) request.  The ARP -a  192.168.2.100 requests data packet is the hardware EUI-48 for the source and target machines and the associated IP addresses.  Each devices OS keeps an internal cache buffer of the EUI and IP associations for all the devices on the LAN.  Regardless of the Operating System being used, Windows, Unix,  Linux they all incorporate an ARP protocol request command as specified in RFC 826.  The IP & EUI combined creates an unique address.  There is also a new format of EUI-48 address for IPv6 it is EUI-64 which will be covered in the IPv6 section.  We will cover more on EUI in the security parts of the series.

IPv4 Routers: The Ins, Outs and Limitations
We have all used IPv4 Internet for a long time now, so it would be easier to relate to IPv6 by securing our understanding of IPv4 and identify the limits then we will move to IPv6.  Our intent in this section is to understand the IPv4 network configuration limitations and how these limitations are addressed and fixed in the IPv6 networks.  Figure 3.2 shows a typical IPv4 Router which includes features to handle the NAT, DHCPv4, Firewall and of course MAC-48 (EUI-48) address filtering allowing programmable control of the devices connected to the Internet.  Control of devices with the IPv4 router is a simple transaction of taking a single IP address from a LAN device like 192.168.2.20 and translating it to the ISP WAN address connecting that single device to the Internet.  Simple, right?; OK, what about say 10 devices on the LAN all wanting to browse the web or upload/download files at the same time.  What happens when many devices try to transfer data to the Internet they all  have to go through the NAT bridge first, then through the firewall to see if that LAN address is allowed passage, then to a single WAN address.  All this traffic from a 10 lane highway narrows down to two single lane bridges, the NAT and Firewall to get the WAN.  Obviously this starts to create a bottleneck or a funnel effect for the traffic since all Internet service providers regulate the throughput traffics (DownLink/UpLink) as shown in Figure 3.3.  For a home and small home office environment this is generally not a problem simply because home users generally adapt to the speeds of the Internet connection and accept the delays.  However for a small office with say 10 or more people working on the Internet daily this starts to become a problem and business efficiency is effected.  For larger companies that have many people on-line constantly this becomes a serious throughput issue.

IPv4 Routers and DHCP:
DHCP (Dynamic Host Configuration Protocol) servers perform a useful task for adding devices to the LAN automatically.   As we stated earlier for a LAN every device must have a unique IP address as well as a unique MAC(EUI) address in order for the LAN to communicate with other devices connected to the network.  With out the DHCP the individual responsible for the network would have to manually keep track and assign all of the IP address for each device and insure its uniqueness.  We see now that the DHCP server eliminates the need for manual efforts to maintain LAN IP addresses.  The DHCP server is generally configured with a block of available addresses like 192.168.2.10 - 192.168.2.40 for a block of 30 devices (10-40) for the DCHP to automatically assigned IP addresses in that range.  After the 30 addresses are used up the DHCP server will not allow any more connections until one of the devices on the LAN is turned off and that IP address becomes available to assign to another device.  From this we see that a device may have different IP addresses from the DHCP server.  This is fine for devices like a smart phone or tablet that is nor always in the LAN area for connection.  However, for a web server or e-mail server this becomes a problem since fixed servers require port forwarding from the WAN↔NAT↔LAN-Server.  Once the range of IP addresses allotted to the DHCP server are used up the user will have to select an IP address outside the DHCP configuration and manually activate the device connection on the NIC.  For IPv4 there is only one DHCP server on the LAN so this becomes an easy task and conflicts are avoided.  The DHCP server or an assigned static IP address function the same via both hard wired through the RJ45 or through WiFi.  However, if there were multiple DHCP' servers on the network this now becomes an issue when devices supply conflicting information.  It can also be hard to get a system to have the same address across reboots with DHCP since it is a first come first serve allocation process.

IPv4 Routers and MAC(EUI) Addresses:
For IPv4 the hardware EUI-48 address and IP are on the private LAN through NAT and may only be accessed on the private LAN side through the devices OS (Operating System) issuing  an ARP request.  Many of the IPv4 routers still address the EUI-48 as MAC ID so in this section we will use both together to get use to using EUI.  This  MAC(EUI-48) is also used in the IPv4 router for MAC(EUI) filtering which allows selective devices on the LAN access to the LAN.  When a MAC(EUI) address is set the MAC(EUI) filter will only allow the those MAC(EUI) addresses use of the LAN and other MAC(EUI) addresses of devices that are setup in the filter this includes Internet access.  In IPv4 routers just the MAC-48 (EUI-48) address is entered in a list in the routers non-volatile memory, no IP addresses are associated with the MAC address since they may be any IP address assigned by the DHCP server or manually assigned Static address.  The MAC filtering is only effective on the private LAN in IPv4 router and as stated it is not routed to the Internet WAN.  All NICs connected to the LAN are retrieved via the ARP protocol and stored locally in each computer by the Operating System running on the device or computer.  This is one of the differences between IPv4 and IPv6 schemes as we will in the following sections.

IPv4_Router_Block_Diagram
Figure 3.2  Typical IPv4 Router Functional Block Diagram

IPv4 LAN Capabilities: Overview
IPv4 LAN bridge has three blocks of private IP addressing issued by IANA that the user may choose from as stated in Part-2.  NAT is considered a private LAN and IANA has assigned the following IP ranges, (010.000.000.000-010.255.255.255), (172.016.000.000-172.031.255.255) and (192.168.000.000-192.168.255.255) for that purpose. These assigned addresses fall into the Internet black hole and will not be acknowledged on the Internet.  Table 3.1 shows the configuration settings and the number of devices for those settings.  The IPv4 router has the ability to handle a huge amount of connected devices.  Lets see what happens in the IPv4 network under NAT when many users access the Internet at the same time.  As we see adding devices to the LAN especially if they are to communicate on the WAN globally can easily end up to be a bottleneck of traffic shown in Figure 3.3 below.  

Starting IPv4 Address Ending IPv4 Address IPv4 SubNet Mask LAN Host Bits Number of Devices
192.168.000.000 192.168.000.000 255.255.255.000 8 256
192.168.000.000 192.168.001.000 255.255.254.000 9 512
192.168.000.000 192.168.003.000 255.255.252.000 10 1024
192.168.000.000 192.168.007.000 255.255.248.000 11 2048
192.168.000.000 192.168.015.000 255.255.240.000 12 4096
192.168.000.000 192.168.031.000 255.255.224.000 13 8192
172.016.000.000 172.032.255.255 255.224.000.000 20 1,048,576
010.000.000.000 010.255.255.255 255.000.000.000 24 6,777,215

Table 3.1  Typical IPv4 LAN Addressing Capabilities

Consider each arrow represents a single packet of information (about 1500 bytes) trying to all get to the global Internet to send to the destination.  This also doubles when we are also trying to receive data to many devices connected at the same time.  This is one of the main issues with IPv4 especially for web sites which have to handle large amounts of data in both directions with many users.  Also for ISP connections like DSL that have 1 Megabits/sec (1Mbps) for both Downlink/Uplink this can have a very slow response.  Many cable ISP connections average 5Mbs for both Downlink/Uplink, this is a bit better.  As an example a typical home/SOHO network is like 10Mbps/3Mbps Dn/Up links.   For an average family of four, two children, two adults we would have, four smart phones, four desktop or laptops, Game stations two, Home theater connected. OK two are on game stations, two are on laptops or desktops and watching streaming videos and browsing the Internet.  That is a total of four smart phones, two game stations, two workstations all on at the same time.  That means that total throughput for the network is 2+2+1 = 5 on line would reduce the speed, hence:  10Mbps/5 = 2 Mbps  Dnlink and 3/5 = 600K up link.  For DSL it would be 200Kbps Dn/Up total.  For streaming video, this is at the critical speed and if there is any large transfer for the network you will see intermitting still pictures.

      
Figure 3.3  Typical IPv4 Router Traffic Bottle Neck

IPv6 EUI-48, EUI-64 addresses
Now that we understand how the MAC-48 (EUI-48) address interacts with IPv4 we will cover how the EUI-48 address interacts with the IPv6 addressing scheme.  We will take a short refresher from Part-2 on the IPv6 address format.  IPv6 is a 128 bit address protocol scheme shown in Figure 3.4 and is grouped into eight 16 bit blocks (two octets) that use hexadecimal format (0000-FFFF) separated by a colon.  This gives eight groups of 16 bits in hex format as FD76:938C:03FF:51D3:0000:0000:00D3:000E.  This does get cumbersome at times so to help with the formatting IPv6 has format shortcuts for displaying the address such as, 0000:0000:0000:0000:0000:0000:408:833 may be written as ::408:833.  Leading 0s are also reduced so for the IP address 00EF:0938:00FF:0513:0000:0000:000D:000E may be written as EF:938:FF:513:0:0:D:E.  The size of IPv6 is huge, the largest number for 128 bits (2128) or 340x1036 (340 billion, billion, billion, billion) or 340 Undecillion addresses.

IPv6_Format
Figure 3.4  IPv6 Address Scheme 128 bit Format

OK, what does this have to do with the MAC address? Everything.   The MAC acronym has been formally changed to EUI (Extended Unique Identifier) to accommodate the IPv6 formatting scheme and the full labeling are EUI-48 for IPv4 and EUI-64 for IPv6.  The IPv6 EUI-64 Figure 3.5 has added an additional 16 bits to the format, the OUI (Organisational Unique Identifier) is still 24 bits and hardware Interface ID is extended by 16 bits to yield a 40 bit Hardware Interface IDentifier.


Figure 3.5 EUI-64 Extended Unique Identifier Format

Since IPv4 will be around for some time a conversion methodology was created to use both EUI formats seamlessly.  To convert a EUI-48 to EUI-64 we split the EUI-48 into two 24 bit blocks, flip the most significant octet second least significant bit1=1 (Locally Administered ID) shown in Figure 3.6, insert the 2 octets (16 bit)  FF FE between the two 24 bit blocks then represent the standard IPv6 address hex format as shown in Figure 3.7.  The EUI-48 ID of  AC:DE:49:23:45:67 maps to a EUI-64  AEDE:49FF:FE23:4567.  The flipped bit is to identify the EUI as a physical hardware burned in ID.  At this time it is important to realize that a devices EUI-64 address is incorporated into the IPv6 128 bit address and used by the host router to automatically configure the device to communicate over the IPv6 Network.  The remaining control bits shown in Figure 3.6 are used to identify specific IPv6 addressing functions.  We will address this in the security and hardware communications section of the series.


Figure 3.6 Mapping EUI  Locally Administered ID  b1=1

So the Ethernet EUI-48 address AC:DE:49:23:45:67 converts to AEDE:49FF:FE23:4567 for the lower 64 bits of an IPv6 EUI-64 address shown in Figure 3.7, called the "Interface Device IDentifier" to be sent to the host router for an IPv6 address assignment and configuration.  If this was in a ULA network say FE80::/64 it would become   FE80::ACDE:48FF:FE23:45676   


Figure 3.7 Mapping EUI-48 To EUI-64 Locally Fixed Hardware ID

All smart phones transmit the EUI-64 address when connected to the Internet and may be tracked easily with IP tracking software, another discussion in the Security part of the series.  The IPv4 and IPv6 addressing schemes differences in that the EUI-48 in IPv4 is kept on the private LAN and not routed out by the router to the Internet.  In IPv6 the EUI-64 is routed by the end users local router to the ISP global router, assigned an IPv6 address and configured outside the users private network.  This means that all devices on IPv6 point to point are identified outside the private network and the user no longer has private control over the devices configuration activities.  As we progress through the series we will be identifying these unique differences and create a methodology to implement into our core platform that will allow more user control.

OK, lets summarize at this point, the reason being is IPv6 tends to become more difficult to keep in perspective from this point on.  We have covered in this part, the changing of terminology from MAC (Media Access Controller) to EUI (External Unique Identifier), How EUI-48 and EUI-64 are formatted, the IPv4 router capabilities and how they relate to the EUI-48 LAN through NAT.  We covered the depth of IPv4 device control and the IPv4 firewall again using NAT.  We also created a table for the IPv4 LAN number of addressing capabilities of an IPv4 private LAN. As shown  which has been handling company sizes from a single employee to fortune 500 companies with very large number of networks devices.  We showed that every Device IDentifier regardless of the IP scheme has an associated IP address when connected to a network.  In IPv6 we use the EUI-64 as part of the full 128 bit IPv6 address, if this device was attached to a ULA private network say FE80::/64 it would become FE80::ACDE:48FF:FE23:4567.  The new item here is that the EUI is now part of the IPv6 full address regardless if it is on a private or global network.

IPv6 DHCPv6, SLAAC vs Stateful (Manual Device Assignments):
Handling Devices on the Private & Global Internet Bus

This section is where IPv6 separates itself from IPv4, we loose some features and gain some features. The main feature we loose is NAT, IPv6 has way too many addresses (340 x 1036) and has been stated that NAT is not needed any more.  We will get back to that later in the series.  The elimination of NAT creates another concern.  The ULA (Unique Local Address) discussed in part-2 is a "real private network" that is not routed to the global Internet.  The default ULA is FE80:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx The majority of routers that incorporate IPv6 also incorporate IPv4 as a dual mode router, the user selects the mode to setup either IPv4 or IPv6 not both.  Since NAT is not designed in on IPv6 it is safe to say NAT is only used with IPv4 mode is selected for setup. This is different from the IPv6-Ipv4 Dual-Stack scheme that uses a translator to switch schemes and has been assigned by IANA and ICANN to handle the transition from IPv4 to IPv6 upgrades.  We have created a couple of block diagrams to show the functionality differences of IPv4 Figure 3.8 and IPv6 Figure 3.9 routers. It becomes clear that the IPv6 router is more complex when attaching devices to the Internet, however the IPv6 ULA private network functions similar to the IPv4 LAN except for the facet that there is no NAT to connect a device to the Internet.  This does create an issue about device control and we will be addressing that in detail as we design the core IoT platform as the series progresses.

We see that the IPv6 ULA function is a separate function that is not routed to the Global Internet.  The WiFi connections for the ULA are separated from the Wifi for the Global Internet.  The eight port managed switch insure that ULA is not routed to the Global Internet.  The router configuration allows the user to select the ULA and Global configuration.  Routers usually have four or eight RJ45 ports for hard wire and maybe other external switches to increase the number of wired connections.  The EUI-64 addresses for devices connected to the ULA are maintained in a cache by the connected devices operating system.  In IPv4 we used ARP(Address Resolution Protocol) request in IPv6 we use a NDP (Neighbor Discovery Protocol) that is very similar in nature that is also works only on the ULA network and is not routed to other networks.  The IPv6 DHCPv6 server works similar to the DCHPv4 server in IPv4 routers except in IPv6 the ULA device addresses are not routed to other networks or the Internet.


Figure 3.8  Typical IPv4 Router Functional Block Diagram

 

IPv6_Router_Block
Figure 3.9  Typical IPv6 Router Functional Block Diagram

IPv6 DHCPv6 and Manual Device Assignments:
From the above routers functional block diagrams we see that for IPv4 LAN and IPv6 ULA networks allow both DCHP servers and manually assigned Static IP addresses for the private network.  This allows the private network to communicate with a huge number of attached devices.  The ULA becomes a true protected private network when working in a development environment such that the local private servers will only be accessible to devices on the ULA network, outside Internet networks are completely isolated.  The DHCPv6 server becomes very helpful for connecting new devices over WiFi  connections. Both Static IP and Dynamic IP may share the same network by assigning a range to the DHCPv6 server.  Static IP's on the ULA are useful for network servers for client server application software and is easier to manage with fixed static IP addresses.  To get the Associated IP/EUI for each device we issue a NDP (Neighbor Discovery Protocol) RA(Router Advertisement) request and the return is a listing of EUI-64 to IPv6 addresses for each device connected to the ULA network.  Devices may be added to the ULA private network without any communications with the ISP global router.  What we need is a network control switch that will just transfer the EUI-64 to the global Internet which will assign two IP addreses to a single device, one for the isolated private ULA network and one for the SLAAC on the Global Internet.  This wil be addressed in the platform design section of the series.

IPv6 SLAAC Device Assignments:
Here is where everything changes, the global Internet device configuration function called SLAAC (StateLess Address AutoConfiguration).  To make this as simple it as possible, look at autoconfiguration as DCHP is local private network function and SLAAC is the Global Internet function. SLAAC works similar to DHCP in that it requires a EUI-64 to assign an IP address to the EUI-64, however the ISP controls the IP assignment.  The local router at the end users site allows the ULA network user to have complete control over the devices connected to the ULA network. However, SLAAC requires that the ISP subnet router have control over the device configuration and IP assignments.  This is much different than the IPv4 router that allows the user to control access through the MAC(EUI) address.  With IPv6 we hand that control over to the ISP which means the end user has less control over devices.  For those who run a SOHO business and have on-line servers this become more difficult since we would need a fixed IPv6 address with some type of port forwarding to control the access to the server and the end users router would have to have EUI filtering to insure the server is accessed by the end uses router and not by any unknown router.  It would make sense that the ISP would also be capable of assigning a block of Static IPv6 addresses from their subnet router to perform this function.  This would allow the local end users router to control the EUI to IP locally as well as port forwarding to say a web server or e-mail server or security devices, this is a Stateful or manual function.  This would not be a good practice for a larger group of desktops or laptops to run on Static IP's since as we have seen the number of devices increase easily in a short period of time. A small block of static IPv6 addresses like less than 24 would be easy to handle manually.  The ISP that I have worked with all charge a nominal monthly fee for a block of static IP addresses, considering the addressing capability of IPv6 fixed IP's should not be an issue.  This will be an important topic when we get to the security and firewall section of the series.

The process for SLAAC is straight forward, the ISP network routers send out a RA (Router Advertisment) which is a function in the NDP (Neighbor Discovery Protocol).  This request happens periodically to insure the network is assigning IP addresses to EUI-64 devices efficiently and keeping track of who is connected to the network.  This is very similar to DHCP servers that drop and reassign IPs depending who is connected to the network. the difference is this is the global network and not a small private network.  What has to happen here is the ISP router needs the EUI-64 to complete the full IPv6 address.  The IP-64 should be a unique ID address and traditionally the bottom 64 bits of the IPv6 address is generated from the EUI-64 ID.

This section gets to be a bit more technical, so to bring it down a notch or two before diving into the pond, look at all IPv6 commands, requests are stimuli and of course the is a response to these stimuli.  There are two sources for the stimuli, the devices operating system and the ISP router, just like clicking on say a file explorer application, the response are a listing of attributes about the storage, directories and files.  Same for the IPv6 network requests, stimulus and response, with that in mind lets move forward.  With IPv6, a DHCP server is not necessary because the ISP global subnet router handles the assignments and automatic configuration.  The process for this IPv6 function is called SLAAC (StateLess Address AutoConfiguration).  As we lightly mentioned in Part-2 it is a mechanism that when a device is connected to IPv6 it is auto configured by the host router and is able to start communicating immediately.  This is accomplished by the IPv6 routers sending out a RA (Router Advertisements) that mask bottom 64 bits (all 0s) of an IPv6 address, and hosts (ISP) router generates the bottom 64 bits themselves in order to form a complete address.  This relates an IPv6 address with a Interface Hardware ID and is used to insure the P2P data transfer completed.  Alternatively, a host may also generate its IPv6 address using a random number so its MAC(EUI) address remains hidden from the rest of the Internet.  Creating EUI-64 addresses randomly and hide the hardware EUI-64 from the Internet.  This is part of the EUI-64 control bits which we will cover this in the security and firewall section of the series. So far only the very expensive routers like Cisco® and other in that category have the more advanced capabilities and are way out of the price margin for home/or SOHO use.  When this happens a simple connection like VoIP from the home network continue over the wireless network to any destination away from the home, it just uses the static/fixed IP address over IPv6.  Carriers like Verizon, Sprint, and many other are already switching to VoIP service to move to Multihoming.  So as we are experiencing network technology is full of acronyms and this is just the beginning.  This is why we are starting at the very basic to get the concepts in perspective, then a new acronym will be easier to handle, just like programming, there are groups of common commands with different pseudonyms however they all perform the same function.

We will cover SOHO servers under IPv6 like web,e-mail and database type servers.  Servers are relatively straight forward with IPv4, a static IP and port forwarding through NAT.  The ISP is required to have some type of dashboard for the DNS (Domain Name System) hosting service.  This sets up a A record for IPv4 and the AAAA record for IPv6 to point to a specific IP address so the entire Internet will be able to access the server by domain name, through ICANN and IANA.  This allows the SOHO to control their own server and control the access.  This also fits into the security and control sections of the series.

 

Summary:
The IPv6 specification is now 20 years old so any major changes are not likely to happen any time soon.  As for NAT you would think after 20 years of discussion and not implemented it is not going to happen.  That does not mean it will not be featured and translated in devices some other way for convenience, control and security.  We have presented a basic entry level introduction to the both Internet Protocol schemes we are using today.  As we stated Network Technology is full of acronyms to categorize network operations and we have just touched the surface, Table-3.  I talked with my ISP the other day and discussed the IPv6 Fixed IP block of addresses and the number of devices I can attach to the Internet with SLAAC.  The IPS offers /56 block of IP connections using SLAAC. The /56 means the bottom 8 bits of the SubNet and 64 bits for the Interface Device ID are the end users selection.  The ISP also offers a block of  IPv6 Static IP addresses for a nominal fee in blocks of 5, 12, 24 addresses.  The static IP addresses will allow for port forwarding for on-line servers at the end users site.

From this discussion we begin to see that IPv4 firewall is no longer suitable for IPv6 and clearly shows that a new interface technology is required in order to maintain device control and some advanced firewall topology for the IoT devices connected. What is inevitable is that IPv6 will change the secuirty policies that are present in IPv4.

 

Acronym Name Description  - Stands For Protocol
WAN Wide Area Network IPv4 and IPv6
LAN Local Area Network IPv4
ULA Unique Local Address - Private Network
IPv6
NAT Network Address Translation IPv4
P2P Pear to Pear or Point to Point IPv4 and IPv6
DHCPv4 Dynamic Host Configuration Protocol IPv4
DHCPv6 Dynamic Host Configuration Protocol IPv6
SLAAC StateLess Address AutoConfiguration IPv6
Stateful Stateful Manual Configuration IPv6
MAC Media Access Control IPv4 and IPv6
EUI Extended Unique Identifier (new MAC) Ipv6
ARP Address Resolution Protocol IPv4
NDP Neighbor Discovery Protocol (new APR) IPv6
Unicast Single end to end data packet transfer IPv4 and IPv6
Broadcast Single to Many data packet transfer IPv4 and IPv6
Multicast Single/Many to Many in network IPv4 and IPv6

Table 3.3  Update of Table 1.0 Basic IP Acronyms

The next part of the series we will address the Global and ULA private networks and the protocols used to configure and control devices on IPv6. This will bring us another step forward to characterizing our IoT core platform to connect as a dual mode IPv4 or IPv6 network device.

 


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) - Security, Privacy, Safety - The Information Plaground Part-3: IPv4,IPv6 DHCP, SLAAC and Private Networks: (November 25, 2016)

For Website Link: cut and past this code:

<p><a href="https://basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=4&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) - Security, Privacy, Safety - Platform Development Project Part-3 - IPv4,IPv6 DHCP, SLAAC and Private Networks: (November 25, 2016)</p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-2

saltuzzo | 11 November, 2016 09:24

Part 2: IPv4 and IPv6:
The Ins and Outs of IP Internet Addressing

“Creativity expands the mind, stretches it beyond ordinary human comprehension, resulting in the mind being elastic and capable of transcending and discerning complex ideas.” - Michael Bassey Johnson

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016)
Part 3 IPv4 & IPv6 DHCP, SLAAC and Private Networks
- The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 IPv4 & IPv6 Protocols
- Network, Transport & Application (January 10, 2017
Part 5 IPv4 & IPv6 Protocols - Continued - Network, Transport & Application  (Aug 17, 2017)
Part 6 IPv4 & IPv6 Protocols - Network, Transport & Application Continued (Sept 24, 2017) 

Lets Get Started: Quick Review to Set the Atmosphere for Part 2
From Part 1 we see there are many categories to address with IoT devices.  We will cover the legal aspects mentioned in Part 1 in our Law and Technology Blog section at another time.  Since this is an IoT design series, our objective is to create a core IoT device development platform from the basics to the complex, complete ready to be implemented, incorporating complete security and end user control, both IPv6 and IPv4.  BASIL Networks, PLLC always encourages education and growth through understanding the sciences.

As stated in the Part 1, the diminishing of IPv4 Internet addresses was the catalyst for the development of IPv6.  The connection issue with both versions have created a lot of difficulties in understanding the uniqueness between IPv4 and IPv6, what parts of IPv4 will be discontinued, how this affects the privacy of IPv4 and IPv6 customer base.  Where this becomes an issue is converting the home and SOHO network which is primarily IPv4 over to IPv6.  IPv6 20th anniversary RFC1883 IPv6 Specification was published January 1996 and to date 2016 about 15% of the total global Internet has converted to IPv6, the USA being over 35% at this time.  To put that in perspective, in the USA the government set forth a mandate that all DoD and civilian providers upgrade to IPv6 by 2008.  Well that has been eight years ago and the majority of the ISP (Internet Service Providers) have upgraded at least several of their servers so they met the requirements.  However, the majority of the businesses, SOHO and family home networks are still running IPv4 networks.  There are many published articles outlining the pros and cons about making the transition at this time, it has only been 20 years.  We will address how this transition will affect the privacy of the home and SOHO networks and how much time remains before a mandatory change is imminent.  We are still in the fact gathering educational stage of this series to categorize the unique characteristics of IPv6 and IPv4 in order to create our TSD (Technical Specification Document) used as a guide to design our core IoT development platform.

IPv4 - IPv6: Information Highway Bubble
In this part of our IoT design series we will be covering the basics of the IP (Internt Protocol) addressing, how it works and why it is exposed to any that want to listen in on the global Internet “Information Highway”.   Do not worry about this being to technical to understand, for those that are just beginning to understand IP network technology we will relate this to things you already understand and do naturally. For those more technical including myself found this a refreshing review  hope you will to.

IANA and ICANN: Internet Core Basics
Everything on the Internet "Information Highway" is identified by a number, an IP address to on both ends is required for communications just like cell phone numbers, building addresses and so-on.  So information flows from Point A to Point B.  The TCP/IP (Transmit Control Protocol / Internet Protocol ) is a Point to Point (P2P) protocol.  

There are two major organizations that manage the Internet Protocol throughout the entire Internet, they are, IANA (Internet Assigned Numbers Authority) and ICANN (Internet Corporation of Assigned Names and Numbers).
IANA - Internet Assigned Numbers Authority manages all the IP addresses that are assigned to all the Internet Service Providers globally.   This insures that each IP address is unique in order to comply with the TCP/IP P2P protocol requirements.
ICANN - Internet Corporation of Assigned Names and Numbers manages all domain names associated with IANA IP number assignments.   This insures that a single IP address is assigned to a single domain name.

A Simply Analogy To Understanding The IP Address:
Before we get to technical with IPv4 and IPv6 lets look at something similar that we use and understand in our everyday lives.  Lets say you want to mail a package to a person in another state and what is interesting is that the house number and street name are the same as yours, however the package seems to be able to be delivered without issue.  Great, lets break this down to see how this is works.  To start we will assign some labels to the postage delivery path, here in the USA the ZIP Code is used, since each State has their own Postal ZIP Code this will get the package to a local county region from there the postal delivery agent identifies the street name and number and delivers the package.  Simple table below.

Address From Point A

Address To Point B

ZIP Code, State Prefix
ZIP Code, City Prefix
ZIP Code, County
Street Number and Street Name

ZIP Code, State Prefix
ZIP Code, City Prefix
ZIP Code, County
Street Number and Street Name

So now we have the P2P map for the delivery of the package.  We can easily convert this total delivery system to a numerical system and create four groups or classes for this new numerical system, Class A, B, C and D.  This is now a global number system that is independent of country.   Fortunately the global populous has been using the various postal systems for a several centuries now and have integrated it into their lives as a normal level of knowledge.  The global populous has also integrated usable technology into their lives a normal level of knowledge and now we are expanding that level with the integration of IPv4 and IPv6.  We use the Internet without thinking how it actually functions, the same as we mail a package.  Somewhere in the back of our minds we actually do understand how it works we just do not think about it, we just apply it.   The table below connects the dots for ZIP Codes and Class type networks and crosses that analogy bridge. As we see the Classes identify with groups of the IPv4 and IPv6 protocols and they are the same except for the number of numerical addresses for each group as we will clearly see.

Postal Map Class ID IPv4 IPv6

Zip Code, State Prefix
Zip Code, City Prefix
Zip Code, County
Street Number and Street Name

Class A
Class B
Class C
Class D

Prefix
GlobalID
SubnetID
InterfaceID

Prefix
GlobalID
SubnetID
InterfaceID

Ok we have now been able to reach the actual house of the destination for the package and delivered it.  Ok  so we open the package and find a gift for the kitchen, so lets go one step further and label the rooms in the house also with a numerical identity labeled PortID.  We will address the PortID later on. Lets focus on the addressing paqrt first, the PortID is an addon to the addressing.

Now relating this postal map and classes to the IP protocol addressing scheme seems to be a lot easier when there is an analogy to something we understand.   Since the Internet deployment of a 32 bit protocol yielding four billion (4,294,967,296 = 232) P2P communications, running out of addresses was not really considered probable at the time IPv4 was deployed.  Since the deployment of IPv4 in the late 70's early 80's took less than 10 years growth to realize the limitations of running out of addresses.  Well here we are today and IPv4 has less than 10% remaining addresses.  When we look at the whole world population and growth, this now seems a simple thought that we would run out of four billion address considering there are over 6 billion people on the planet, growth was the catalyst that started the development of IPv6.  Now that we are at this point lets look at the two protocols IPv4 and IPv6 and how they differ.

As we see the postal codes globally were developed on an as needed basis and each country created its own way of coding.  Well the world was populated by many before the "Information Highway" was organized and it was easy to see that a straight numerical system globally would be easier to manage.  The 32 bit addressing scheme for IPv4 protocol is grouped into four octets separated by periods (000-255 decimal, 00-FF hexadecimal).  IPv4 uses the decimal format of 000-255 instead of the hexadecimal that yields 255.123.255.255, classes A, B, C, and D.  As an example, this website is registered with ICANN as "basilnetworks.com" to the IPv4 address 64.139.76.51.  IPv4 represents each octet in decimal format however, as we transfer to IPv6 this changes to hexadecimal, and part of the IPv6 address for "basilnetworks.com becomes 408B:8C33 in hex format.  Figure 1.0 shows the IPv4 protocol addressing.  Considering today's number of registered domain names exceeds one billion and growing.

IPv4_Addressing
Figure 1.0 IPv4 basilnetworks.com IP Address

Switching to the IPv6 Address:
IPv6 is a 128 bit address protocol grouped into eight 16 bit blocks (two octets) that use hexadecimal format (0000-FFFF) separated by a colon.  This gives eight groups of 16 bits in hex format as FD76:938C:03FF:51D3:0000:0000:00D3:000E.  This does get cumbersome at times so to help with the formatting I has shortcuts for displaying the address such as, 0000:0000:0000:0000:0000:0000:408:833 may be written as ::408:833.  Leading 0's are also reduced so the IP address IF:938:OFF:513:0000:0000:003:000 may be written as IF:938:FF:513:0:0:D:E.  The size of I is huge, the largest number for 128 bits (2128) or 340x1036 (340 billion, billion, billion, billion) addresses, a bit more addresses than IPv4.   Enough for many devices. Great, the addressing issue with the Internet is fixed so what changed in order to obtain this huge address?

IPv6_ClassAdr
Figure 2.0  IPv6 IP 128 Bit Address Assignments

IPv4 Network Address Translation (NAT) verses IPv6 Unique Local Addressing (ULA)
IPv4 Private Networks: LAN (Local Area Network)
Here is where it starts to differ and become a bit more technical.  IPv4 uses a technique called NAT (Network Address Translation), a technique of using only one global IP address and translating it to a local private block of addresses called a LAN (Local Area Network).  It was created to extend the address range of IPv4 as not to run out of addresses too soon.  NAT became the standard and allowed several devices to be controlled and still have access to the global Internet.  However, whenever you translate data in any form there are delays and software overhead to account for that creates shortcomings using NAT.  Today's new developments in technology such as VoIP and streaming video protocols etc. that require direct point to point global IP addresses create IPv4 limitations and are addressed with special software to identify that a NAT protocol is being used again, at the expense of throughput.  NAT is considered a private LAN and IANA has assigned the following IP ranges, (010.000.000.000-010.255.255.255), (172.016.000.000-172.031.255.255) and  (192.168.000.000-192.168.255.255)  These IANA mapped IP addresses have no response on the global Internet and go into the global Internet black hole.  This allows these LAN addresses to be router controlled transferring data to/from the global Internet or WAN (Wide Area Network).  LAN addresses 192.168.000.000-192.168.255.255 through NAT, (WAN↔NAT↔LAN) are generally used as the private internal network for the home, SOHO and business environment prior to IPv6.

Many IPv4 routers are shipped with a default of 192.168.1.0 or a given IP in order to easily setup the router.  The IPv6 discussion is that since IPv6 allows enough IP addresses to handle devices NAT will no longer be required and will be discontinued.  We will get to how this is handled in the following paragraphs.

IPv6 Private Networks: ULA (Unique Local Address)
Private Networks in IPv6 are handled a bit different.  IPv6 however does have a LAN, but it is called ULA (Unique Local Address), the address is IANA mapped as anything above FDxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx, the “difference” being is that the ULA is completely isolated from the outside world and cannot be routed to the Internet like the LAN for IPv4.   The IPv6 ULA must always remain behind the routers global Internet transport mechanism.  IPV6 will be universally implemented over time and is moving towards the home family network environment slowly however this implementation will increase as providers upgrade to IPv6.  Providers like Comcast®, Cox®, Time Warner® and many others are already providing IPv6 connections to their customers.  Keep in mind the majority of home networks are still IPv4 and to requiring them to upgrade to IPv6 may cause other privacy issues as well as incompatible hardware and software issues at this time.  Figure 2.1 shows the IPv6 128 bit addressing format.  The L bit is the top octets least significant bit and determines the ULA or Global Internet mode.  The top eight bits are FC for Global Internet and FD for ULA.  Figure 2.0 below shows the IPv6 protocol address range is large enough to handle all the desired devices that may be connected globally to the Internet.

IPv6_ADR
Figure 2.1 IPv6 Protocol Address Range

At this point we should be asking about the privacy issues and device control with IPv6.  Since the IPv4 NAT is no longer required to translate a block of local addresses in the IPv6 protocol then the devices connected are either totally blocked using ULA or globally routed Internet devices.   The website IPv6 covers everything you ever want to know about IPv6, technical and general, we will be utilizing the technical data for the later parts of this series.

Many of the medium to large businesses have already made the conversion to IPv6, however many are still running IPv4/IPv6 dual system.  This dual-stack IPv6/IPv4 implementation outlined in RFC 2893 allows the IPv4 class for communications between the two protocols and is recognized as, the IPv4-mapped-IPv6 addresses.  The 128 bit IPv6-IPv4 class addresses consist of an 80-bit prefix of zeros, the next 16 bits are one, and the remaining, least-significant 32 bits contain the standard IPv4 address mapping.  The basilnetworks.com IPv6 address would be ::FFFF:64.139.76.51.  The dual-stack implementation has been argued to introduce more security threats as hosts could be subject to attacks from both IPv4 and IPv6 however, it is the better implementation during the IPv4 to IPv6 conversion process.  On a browser to access an IPv6 site basilnetworks.com directly would look like http://[0:0:0:0:0:FFFF:64.139.76.51]/ notice the brackets enclosing the IPv6 address or for full IPv6 notation http://[0:0:0:0:0:FFFF:408b:4C33]/ (64.139.76.51 represented in hex=408B:4C33) and for IPv4 it would just be http://64.139.76.51/. This dual stack is the interim fix being used for the transition from IPv4 to IPv6.

IPv6_IPv4_Stack
Figure 3.0 IPv6-IPv4 Dual Stack Mapped Protocol Address Range

Network Privacy Conundrum: “The Big Deal”
As we see the addressing capabilities from IPv4 (32 bit) compared to IPv6 (128 Bit) are over 340x1036 larger.  The issue with the transition to IPv6 is the elimination of IPv4 NAT in the IPv6 protocol and the new requirements for privacy and security with this transition.  The TCP/IP is an OSI (Open System Interconnect) and is just a transport agent for data point to point.  The privacy and security is the responsibility of the user, the TCP/IP just transports data.

Device privacy, blocking the device from the global Internet within an IPv4 network is controlled by a firewall that is generally integrated into the router.  There are many choices for IPv4 routers on the market today and will be for some time.   Some ISP’s supply the routers like Comcast® while others allow you to supply your own.  Either way the majority of these IPv4 routers come with a decent if not robust firewall.  Blocking a single device like a printer from Internet access outside, the IPv4 LAN is an easy task for the IPv4 Firewall, just add the devices IP address to the firewall security policy for outbound and inbound traffic and only the devices connected to the LAN will have access to it while other devices that are on the LAN that are not blocked communicate are translated to have access to the global Internet.  If the user decides to allow the printer address to be routed to the global Internet just remove the security policy block from the firewall.  The router will complete the gateway communications from the LAN to/from the WAN.

The IPv6 class protocol does not include NAT as in IPv4, what IPv6 incorporates is a private network class called ULA (Unique Local Address) area network and this ULA is “not routable” to the global Internet like the IPv4 NAT-LAN is.  There is no NAT like IPv4 directly with IPv6 which brought up an interesting challenge to the Internet Engineering Task Force (IETF) to solve.  The challenge for the time being is answered by the use of the IPv6-IPv4 dual-stack until all the systems are upgraded to IPv6.   The dual-stack will remain in use for some time since less than 20% of the global Internet is IPv6.  The major players like Comcast®, Time Warner® etc. utilize the dual-stack IPv6-IPv4 class in order to accommodate the millions of user’s family and SOHO accounts that are using IPv4 networks.

Summary IPv4:
In IPv4 we used one IP address through NAT and were able to assign by the user without ISP involvement up to 255 devices for each subnet incorporating NAT and control whether these devices were to be blocked from the global Internet or not with a simple security policy through the integrated firewall.  NAT flexibility comes with a throughput issue since additional software overhead is required to translate the LAN to/from the WAN.  In IPv6 we are either on the global Internet “or” on the ULA private network which is not routable to the global Internet.   IPv6 routers that come with integrated firewalls are still being developed and are limited to accommodate the full capabilities of IPv6 at this time.  This will change over time as the demands to upgrade to IPv6 become more applicable.

The IPv6 ULA Challenge: User Control of the IPv6 IoT Devices
On a positive side using IPv6 ULA gives the "ultimate" protection to the private internal network eliminating access to the internal networks from outside hackers.  From this series point of view it eliminates one of the problems of outside control of IoT devices inside the home/SOHO network.  However, if any of the devices have a need to be on the global Internet network in any way, it will have to be on a separate network global IP address with no communications to the ULA private network.

On the not so positive side of the challenge, The IPv6 class protocol allows all devices to be connected to the global Internet, which is the intent of IPv6. Global Internet connected devices are given the ability to talk to each other and be monitored without having to translate addresses through a router (NAT) or special Application Level Gateway (ALG).  Having total device addressing publicly accessible is the future planning of IPv6 communications.  This is where privacy issues appear and have to be addressed.  Imagine someone in another country being able to view your environment or even the vulnerability of being hacked and having your thermostat turned off in sub zero weather in the middle of the night.

Summary IPv6: Device Control with IPv6 On-Line:
Ideally devices connected to IPv6 ULA will communicated to any other device or controller on the ULA and is completely isolated from the global Internet.  In order to actively control a device connected to IPv6 global Internet a separate firewall is required for the specific IP addresses in order to control access from other devices or unwanted hackers.  Keep in mind that those breaches you read about also have very expensive firewalls as well.  IPv6 firewalls for the home and SOHO are still being developed, some of the IPv6 routers available have limited firewall capabilities however, this is expected to change over time since the market is huge and competition will force the development of more robust firewalls.  We will cover firewalls and device control in the design series at a later date.  At this time we are just categorizing the issues we have to take into account for the development platform.

IP Address Ports:  How they are used with the IP Address
We are now ready to bring up the PortID again, remembering the package delivered to the house with a gift for the kitchen, you would want to keep it in the kitchen PortID.  A little about IP address ports, there are 65,535 of them for each IP address, that is like having a house with 65,535 nooks, rooms and little places to put things.  The complete list of port assignments can be found at PORTS.  Ports are used for directing data traffic of a specific type like when you download a file from the Internet using http port 80 or FTP port 21.  Since each IP address has 65,535 (216) ports each address has the capability handling multiple tasks like a web server on http is assigned PortID 80 and a mail server (POP3)  assigned PortID 110 which means data will only travel through the assigned PortID.  IP address ports usage form have not changed from IPv4 to IPv6, they are handled the same way with a slight modification on the IPv6 address notation due to the size.  IPv4 notation would address a PortID at the end of the address with a colon as  http://64.139.76.51:21 to access the FTP port on a server.  IPv6 PortID form is very similar http://[0:0:0:0:0:FFFF:408B:4C33]:21 to access the FTP PortID on a server we still use a colon  but it is after the bracketed enclosed IP address.  Ports are still accessed with a colon after the IP address.  As we see with ports they are like a water pipe that services many houses on a street, they may be turned on or off at any time.  PortIDs are used for many different device and server applications as we will cover during the design process for our IoT core platform.

The Family / SOHO IPv4 & IPv6 Networks: Overview
When we look at the typical IPv4 network that is in the home/SOHO environment being used by both family and business as shown in Figure 4.0 below we can easily see how fast the number of devices added to the network increases and if the business starts to grow the decision to add a private e-mail and web server is put on the table.  Private web and e-mail servers allow business protection at a legal level as well as an information protection level.  Many SOHO offices do not have a web server or an e-mail server in the home environment so without the SOHO servers shown in Figure 4.0, family and SOHO networks are the same. Many of the SOHO operations the web and e-mail servers are outsourced, generally to the ISP or some other web hosting platform.  With an IPv4 network device privacy is a simple task as we explained in the Network Privacy Conundrum section above.   The issue is all communications to the global Internet is performed via the LAN where family members and business requirements have shared access.  This shared access creates an interesting challenge since some family members browse social networks, web sites, gaming sites etc. that may or may not have good security guards to prevent a hacker from accessing the family members smart phones, tablets or desktops.  When we look at the majority of homes that have Internet connections we have the typical wireless setup shown in Figure 4.0.  The IPv4 WAN↔NAT↔LAN controls devices through Network Address Translation (NAT) in order to accommodate many devices on a single IP address, it is just added as needed and the Dynamic IP is assigned on the fly.  This IPv4 network is easy to setup and easy to control the devices you want to allow connection to the global Internet.  Figure 4.0 is a typical Wired and/or Wireless network.  The routers today usually have 4 or 8 local hard wired ports that may be used for direct connect to the device or through a switch to add more devices.  Each subnet in IPv4 will handle over 253 devices and are all time shared through one IP address, so if everyone is browsing the Internet at the same time, the throughput speed is divided by the number on-line. Normal throughput for household accounts with cable is in the 10Mbs/5Mbs DownStream/UpStream and 1Mbs/0.5Mbs for non-cable like DSL and Satellite.

There are two types of connections when you setup an Internet account with and ISP, a Static IP address or Dynamic IP address.  The Dynamic IP address is terminated and reissued over a time active period controlled by the ISP, during the renewal all Internet access is terminated usually for a few seconds.  The Static IP address is fixed IP like the IP address for basilnetworks.com (64.139.76.51) and will remain active indefinitely.  This is a recommended type IP for the standard IPv4 WAN connection and is better for running a separate web and e-mail server if it is decided on in the future.  For networks that are not going to run separate servers then any ISP service will work.  If you want to separate the business SOHO from the family which is also recommended to do, you will be required to get an additional IP address.  Generally the ISP would assign a couple of IP address to each account to accommodate this, if not then there would probably be a small additional charge for this.

There is still concern about IPv6 and how addresses are to be controlled and the amount of user interaction over the control of devices on the global Internet.   IPv4 gives the user a lot of control over devices through the IPv4 router and incorporates a separate DHCP (Dynamic Host Configuration Protocol) server. There is DHCP in IPv6 as well it is labeled DHCPv6 along with a service for the global Internet which is called SLAAC (StateLess Address AutoConfiguration) protocol.  SLAAC allows a device connected to the global Internet to be assigned an address automatically at the global Internet level and start communicating immediately.  There is a manual configuration to this as well, StatefFul, manual address configuration.  This gets a bit more technical and it is the next step to understanding device control with IPv6.  Our next part will cover how IPv4 and IPv6 differ in handling these device protocols.

If this was an IPv6 network you would need a separated IP address for each device and would be linked and no NAT would be used.  The ISP would have to assign a block of IP addresses to be used in the ISP subnet and insure there would be an address range that would accommodate all the possible addresses for each account or charge for each additional IP address as devices are added.  I will attach a review of a few ISP policies with respect to IPv6 address assignments.  Here at BASIL Networks we have block of a 12 IP addresses that support several servers on-line.  We are using the IPv6-IPv4 gateway class through the ISP for this area.

IPv4_Network
Figure 4.0 IPv4 Typical Home/SOHO Network

Part 3 IPv4 & IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016) 


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) - Security, Privacy, Safety - The Information Plaground Part-2: IPv4 and IPv6: The Ins and Outs of IP Internet Addressing (November 11, 2016)

For Website Link: cut and past this code:

<p><a href="https://basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=4&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) - Security, Privacy, Safety - Platform Development Project Part-2 - IPv4 and IPv6: <i>The Ins and Outs of IP Internet Addressing</i></a> (November 11, 2016)</p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-1

saltuzzo | 26 September, 2016 09:22

Part 1: Introduction - Setting the Atmosphere

Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016)
Part 3 IPv4 & IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 IPv4 & IPv6 Protocols - Network, Transport & Application (January 10, 2017
Part 5 IPv4 & IPv6 Protocols - Continued - Network, Transport & Application  (Aug 17, 2017)
Part 6 IPv4 & IPv6 Protocols - Network, Transport & Application Continued (Sept 24, 2017)

Where do we start?  

Setting an atmosphere for a topic like this requires solid facts.  It is very important the reader keeps an open mindset in order to address both positive and negative aspects of this thing called IoT (Internet of Things).

Let’s Begin. The techies are not confused; the hackers are not confused at all they see an on-going buffet of opportunities.  However, observations and discussions give the appearance that the average public is totally confused about what IoT is, how it will affect businesses, homes etc. and the questions keep coming.  This series will address the range of what IoT is from the basics to the complex and answer those questions as well as many of the hidden questions that are part of the IoT technology buzz.  Our intent of the series is to enlighten the public on what to look for when purchasing the next generation of appliances that are capable of being monitored through the Internet.  We will start with a short summary with a presentation of facts then advance through actual designs of IoT devices for the technologists out there that are entering into this arena as well as companies that are interested in product development.

The IoT is not a new technology; the acronym arose due to the advancements in chip density technology hence, the amount of features one can put in a single low power integrated circuit.  The higher the chip density the more functions like TCP/IP, Bluetooth, WiFi may be incorporated onto a single low cost chip.  The order of magnitude may be analogous to the first desktop IBM-PC back in August 1981 (64K Memory, 360K floppy disk) to the smart phone today (32Gig Storage, 4Gig software system, Internet, cell Phone network) that is an order of magnitude thousands of times faster and stores millions of times more data, photos etc., at the touch of a screen.  So in summary the IoT is miniaturizing what we already are capable of in larger form factors.

This being said, what’s the big deal? 

The IoT issues are not the number of devices, size or the chip density technology being used, those issues are only limited to ones imagination.  The issues for this discussion relating to the IoT are how many ways will these miniature “connected” devices impact our lives?

The many “active” discussions/debates about Internet Privacy, PII (Personal Identifiable Information), accountability and information access have positioned us in the current debacle for lack of a better word.  Every day we read about Internet data breaches and the millions of PII data that has been stolen by groups, countries and of course the unknown/unidentifiable hacker.  To name a big one – Yahoo system has been breached since 2014 to put the breach data combined in 2016 to over 2 billion.

The Big Deal:

The Global IoT market is an overwhelming new business market that will without doubt change the way people live in just about every country and in every social networking group on this planet (”Earth”-Third planet from the Sun J) at this time.  Many web services and social networks already have facial recognition search abilities like Google’s image search and others.  This technology is easily incorporated into and website for photographers, researchers and investigators especially law enforcement.

Information of all types about individual behavior is the businesses gold mine to manipulate and incorporate into our everyday lives to sell product and as well as other “interests”.  Product marketing is a way of life globally, that is fine and has been the mode of operation for centuries.  The “difference” is the way information is collected, stored, and analyzed; who has it, how it is being used and the list goes on.  It is of no surprise that putting facts like this on the table for discussion creates difficulties and in many cases are held in strictly controlled private business meeting.

The quest to change individual mindsets for product purchases is challenging if not impossible without behavioral data, unless your product is one of those exceptional necessities like soap and a few other sanitary products.  However, stylish or fad type products demand a large marketing effort.  Now just think if you had access to every individual’s personal behavioral habits, likes, dislikes and many other types of personal information and then be able to time your marketing adds to trigger impulse buying.   This is what the new trend in BI (Business Intelligence) and CI (Cognitive Intelligence) is all about.  The IoT devices not only encourage this trend it will make it a norm if the depth of data being monitored is not understood and incorporates some type of accountability.  To date it is not illegal for a business to collect marketing data on their customers or potential customers.  In a public business, stores etc. there are many cameras monitoring the activity of the people entering and purchasing products, how they browse through the store etc.  All Stores are laid out for maximum purchase and actually direct the public through a maze for better product exposure.   Businesses are moving at great speeds to collect and save this data before the courts decide to declare it either unconstitutional and stop the practice or make it officially legal.  Information of this magnitude if allowed on the open network without some type of protection just encourages many other types of behavior including criminal.  When looking at the cost to companies that suffer a data breach and the loss of intellectual property as well as behavioral data give a new level of control for the predator.  Business security weakest link is human behavior as it always has been, be it just neglect, recklessness, disgruntled, begrudged or just not caring about security.

How does this apply to the IoT devices?

The majority (98%) of the current generation of appliances have some sort of microcontroller or microcomputer.  The next generation of appliances will have an enhanced microcomputer that will have embedded Bluetooth, WiFi  or some type of Internet connection that will connect to your local home network or a local public network controlled by the municipalities (SmartGrid).  The home entertainment market is already connected, your smart phone is already connected, game stations are connected all connecting your home network to many other network providers and the list goes on.  Now just think about this for a short time and ask yourself – do you want some person in another country or state able to view when you are washing your clothes, cooking in the kitchen, being able to see your environment inside your house, what temperature you set your thermostat to even listening and storing your conversations while you watch a movie, or while you are driving your vehicle to wherever with your family or friends.  This is just a small introduction of the implications of IoT advanced technology that the legal system has to be prepared to mitigate and hopefully set some sort of guidelines and laws to protect privacy.  This is a double edge sword, on one hand there has to be privacy laws with accountability as well as individual controls to disconnect the IoT devices from the public domain, or disconnect them completely to revert back to manual mode.   The latter is up to the manufacturer and is usually forced on them by the public requirements.   Think if there is no way to disconnect the appliance from the Internet or to completely turn off the wireless connection I wonder how many people would purchase the product.  There have been many attempts to install back doors on private computers in the home and many are still prone – they are called botnets and they infect a smart phone, personal computer, any device with an operating system and are used maliciously for criminal gain.  IoT devices are now part of this arena.  There is no doubt that the automated home is already here and privacy is surfacing more and more and is now a high visibility issue as it should be. 

What Infrastructure Is In Place Now?

The Smart Grid is the main infrastructure network in place nationwide currently the main use is for monitoring and billing utilities, electricity, water and gas.  The Smart Grids main entry point initially is through the Electric meter and incorporates a high power duty cycled transmitter as well as a receiver for other devices to be connected.  The utility companies also use this usage data for load balancing in order to provide a steady service to its customers.  That does not mean that this data is not used for other purposes as well.  The public is not privileged to other type of analysis. 

There have been many complaints about the Smart Grid causing health issues because of the transmission energy levels on continuously timed intervals.  These issues are still being researched and factual data is being gathered and presented to the public and is not well accepted by the utility companies and other businesses that have visions of connecting to the Smart Grid.  You can Google “Smart Grid” and Smart Meter Health Complaints” for more information, be prepared to get a lot of information both good and bad.  The details will enlighten you as to the depth of detailed data being collected. 

What has to be addressed first and at what cost?

The IoT implementation would not happen without the Internet infrastructure upgrade from IPv4 to IPv6, (we will get to that later in the series) which increases the Internet address capability to assign a unique address to every new IoT device that could be imagined for many years.   This infrastructure requires an Internet equipment upgrade that is very costly.

What our research has uncovered is that everyone including governments globally considers IoT to be open game to monitoring everything these products are connected to.  To date there are several of the high end systems in larger companies that perform monitoring of the environmental systems through a network.  In time expect to see many households equipped with custom monitoring systems based on service contracts for these smaller house base systems where the data is collected to private service companies for the “convenience of customers”.

Data Security today is a Risk Management issue and when applied to a product cost it becomes a difficult task to prove the cost effectiveness without an actual breach to reference to.  Therefore in many cases it is held at a lower risk over the product life.  The IoT is in that category and as stated it is open game to all who want to monitor and use that data.  The way this may be controlled is through the end user who either decides during the actual purchases of the product.  If those appliances that have no user control then only the user can decided to buy or not buy and that is if they are aware the connection exists.

Part 2 IPv4 & IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016)


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) - Security, Privacy, Safety - The Information Plaground Part-1: Setting the Atmosphere for the Series (September 26, 2016)

For Website Link: cut and past this code:

<p><a href="https://basilnetworks.com/Blog/index.php?op=ViewArticle&amp;articleId=3&amp;blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) - Security, Privacy, Safety - Platform Development Project Part-1 - <i>Setting the Atmosphere for the Series</i></a> (September 26, 2016)</p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

All comments are monitored prior to posting and will be posted whether pro or con and professional.  Any type of solicitation will not be posted

 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2017 BASIL Networks, PLLC. All rights reserved
webmaster