Designed & Made
in America (DMA)

BASIL Networks BN'B

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

saltuzzo | 10 January, 2017 09:27

Part 4: IPv4, IPv6, Network 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 Network Protocols
- Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums (Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems -Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing (Feb 11, 2019)

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

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)


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.

 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.

Figure 4.2  IPv4 Network Router Request

Figure 4.2A  IPv4 Datagram 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.

Figure 4.3  IPv4 Header Block

 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)


Internet Protocol header Version 4 bits, IPv4 = 4

Version Description Version Description



PIP  P Internet Protocol  RFC1621 - RFC1622




TUBA  TCP+UDP+Big Address RFC1561










IPv4 Internet Protocol RFC791




ST  ST Datagram Model RFC1819




IPv6 Simple Internet Protocol  RFC2460




TP/IPC  Next Version Internet  RFC1475



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

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)


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)

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)


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)

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)

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

Destination IP Address 0-31
(32 Bits)

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

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


ECN 14-15
(2 Bits)


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)


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)

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)

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


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






Internet Control Message Protocol  - RFC792



Internet Group Management Protocol  RFC3376



DARPA Internet Gateway-to-Gateway  -  RFC823



IP in IP (encapsulation)  RFC2003   



Stream - RFC1819, IEN119



Transmission Control - RFC793 Update RFC3168, RFC6093, RFC6528






Exterior Gateway Protocol - RFC904



Any private interior gateway



BBN RCC Monitoring



Network Voice Protocol - RFC741












Cross Net Debugger






User Datagram - RFC768






DCN Measurement Subsystems



Host Monitoring - RFC869



Packet Radio Measurement


















Reliable Data Protocol - RFC1151



Internet Reliable Transaction - RFC938



ISO Transport Protocol Class 4 - RFC905



Bulk Data Transfer Protocol - RFC998



MFE Network Services Protocol



MERIT Internodal Protocol



Sequential Exchange Protocol



Third Party Connect Protocol



Inter-Domain Policy Routing Protocol






Datagram Delivery Protocol



IDPR Control Message Transport Protocol



TP++ Transport Protocol



IL Transport Protocol



Simple Internet Protocol



Source Demand Routing Protocol



SIP Source Route



SIP Fragment



Inter-Domain Routing Protocol



Reservation Protocol



General Routing Encapsulation



Mobile Host Routing Protocol






SIPP Encap Security Payload



SIPP Authentication Header



Integrated Net Layer Security TUBA



IP with Encryption



NBMA Next Hop Resolution Protocol






Any host internal protocol






Any local network



SATNET and Backroom EXPAK






MIT Remote Virtual Disk Protocol



Internet Pluribus Packet Core



Any distributed file system



SATNET Monitoring



VISA Protocol



Internet Packet Core Utility



Computer Protocol Network Executive



Computer Protocol Heart Beat



Wang Span Network



Packet Video Protocol



Backroom SATNET Monitoring






WIDEBAND Monitoring






ISO Internet Protocol


















Dissimilar Gateway Protocol












Sprite RPC Protocol - [SPRITE]



Locus Address Resolution Protocol



Multicast Transport Protocol



AX.25 Frames



IP-within-IP Encapsulation Protocol



Mobile Internetworking Control Protocol



Semaphore Communications Sec. Protocol



Ethernet-within-IP Encapsulation



Encapsulation Header - RFC1241



Any private encryption scheme










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.

Network Sorcery:
The Internet Engineering task Force:  IETF - RFC references

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


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

(8 bits)


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)

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)

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

Destination Address 00-31
(128 bits)

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

HyperText Transfer Protocol - A markup language used for Web communications


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


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


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


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


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


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


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


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


Allow the synchronization of timed events of multiple IoT devices


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

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


IPv4 IPv6


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




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




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

Multicast Source Discovery Protocol RFC3618




Multicast Address Dynamic Client Allocation Protocol




Multicast Domain Name System




Link-Local Multicast Name Resolution




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.

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.

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.

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.

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

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 Network Protocols
- Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums (Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems -Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management (Apr 5, 2018) 
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core PlatformIoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing (Feb 11, 2019)

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:
The Internet Engineering task Force:  IETF - RFC references

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 paste this code:

<p><a href="" 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 (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-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 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums (Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems -Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing (Feb 11, 2019)

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 where the /8 is the number of bits to mask as part of the absolute address.  This relates to the IP address of and a mask of  So the total 32 bit address would be, 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 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 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 - 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.

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, (, ( and ( 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 8 256 9 512 10 1024 11 2048 12 4096 13 8192 20 1,048,576 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.

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


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.


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

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 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums (Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems -Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing (Feb 11, 2019)

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 paste this code:

<p><a href="" 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

«Previous   1 2 3 4 5 6 7 8  Next»
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2018 BASIL Networks, PLLC. All rights reserved