The blog YTD2525 contains a collection of clippings news and on telecom network technology.
In this series, we have been looking at IP version 6, including the different IPv6 addresses, structures of the IPv6 header and packet, and ICMPv6. In the last article, we mentioned that ICMPv6 lays the foundation for other protocols, such as the neighbor discovery protocol for IPv6, which we will begin looking at in this article.
Introduction to the Neighbor Discovery Protocol
The word “discovery” in this protocol name may be a bit misleading, because the neighbor discovery protocol for IPv6 is more than just “discovering” neighbors. The neighbor discovery protocol, or ND for short, helps nodes on the same link perform address resolution, discover available routers, and determine nodes that are reachable. Actually, according to RFC 4861, there are nine different functions that the neighbor discovery protocol performs as highlighted below:
Router discovery—This enables hosts to find routers that are available on the link.
Prefix discovery—This enables hosts to determine what destinations are available on-link and which ones are available through a router.
Parameter discovery—Routers can advertise parameters such as link MTU or hop limit to all attached hosts on a link.
Address autoconfiguration—ND provides a way for hosts to automatically configure their interface addresses to a high degree of uniqueness.
Address resolution—ND replaces ARP for resolving IP layer addresses to link-layer addresses.
Next-hop determination—The way nodes determine the neighbor IP address to send the traffic for a destination through.
Neighbor unreachability detection—The means by which nodes determine that a neighbor is not reachable anymore.
Duplicate address detection—ND provides a node with a way to determine if the address it wants to use is already in use on the link.
Redirect—Routers can advise hosts on a better next-hop to reach a particular destination.
To achieve these functions, neighbor discovery uses five ICMPv6 packet types: neighbor solicitation message, neighbor advertisement message, router solicitation message,router advertisement message and redirect message.
I figure that the best way to drive home these points is to use examples, so we will look at the functions in detail and, as we go on, we will also see how the different ICMPv6 packet types are used to achieve each function.
Let’s begin with address resolution, because we are already familiar with the address resolution protocol (ARP) from IPv4. One of the reasons why ND replaces ARP for IPv6 address resolution is because of ARP’s use of broadcast, which is “noisy” compared to ND, which uses multicast.
We will use a very simple topology of two routers and a host connected to the same switch, as shown below:
R1 has a link-local address of fe80::1, while R2 has a link-local address of fe80::2. I configured these addresses manually. The host, which is running on the Windows 8 operating system, has a link-local address of fe80::240b:2ac8:47c8:8e50. This was automatically configured using a randomly generated permanent interface identifier, as discussed in the third article of this series.
The neighbor discovery protocol facilitates address resolution by making use of two of the ICMPv6 packet types we mentioned above: neighbor solicitation and neighbor advertisement. We will use Wireshark to help us see into this process.
Solicitation basically means to “request for” or “ask,” while advertisement can mean to “give.”
To initiate the address resolution, I will try to ping from R1 to R2 while capturing traffic on the Fa0/0 interface of R2.
As you can see, this ping was successful, but we will go over to Wireshark to see what happened at the backend. I have applied a filter to show only packets with IPv6 address fe80::1. Notice in the screenshot below that, before the ping packets, there were two packets, as highlighted in red – neighbor solicitation and neighbor advertisement. Ignore the router advertisement packet for now, as we will talk about it in another function.
Here’s a breakdown of what happened: R1 wanted to send traffic to R2 but, because it has never sent traffic to that address, it does not have R2′s link-layer (MAC) address. This is the same logic as in ARP. So what does R1 do? It sends a Neighbor Solicitation message for R2′s IP addresses, basically asking: “Who has IPv6 address fe80::2?”. Let’s look at this message in detail.
We will go from the upper-layer protocol to the lower-layer protocol just the way encapsulation will work, so we will look at the ICMPv6 message first.
The first thing we notice is that this is a Neighbor Solicitation message and it is carried in an ICMPv6 packet having a type field of 135. Next, we see that the Target Address is fe80::2; i.e., the IP address whose link-layer address is to be resolved. This ICMPv6 packet also contains theSource link-layer address option which is where R1 specifies its own MAC address. It is only logical that R1 should send its own MAC address in this Neighbor Solicitation message so that the responding host will know how to reply to the sender (R1). As you can see from below, the MAC address of R1′s Fa0/0 interface is c2:00:2c:fc:00:00.
The general format of a Neighbor Solicitation message is as shown below:
As we have seen above, the type field has a value of 135. The code field is 0. The Target Address field contains the IP address to be resolved to link-layer address. The only option that can be contained in a Neighbor Solicitation message is the Source link-layer address, as we saw above.
Now, let’s move down to the IP layer.
There are three things of importance here:
The hop limit is set to 255. This is actually a security feature because, when this message is received at the other end, the receiver knows that the message was generated by a node on the link. If it wasn’t generated by a node on the link, i.e., the packet passed through a router, then the router would have decreased the hop limit by 1 when forwarding that packet thus making the Hop limit 254. ND messages should be between nodes on the same link and not across boundaries.
The source address is fe80::1. This is the IP address of the sender, i.e., R1
The destination address is ff02::1:ff00:2. This address is called the “solicited-node multicast address” of the IPv6 address fe80::2. We need to take a detour to explain what this address is.
Solicited-Node Multicast Address
We mentioned that one of the reasons ARP was dropped in IPv6 was because it was too noisy due to its use of broadcast packets. By using the broadcast address, all nodes received the ARP message, whether those nodes are using IPv4 or not. ND reduces noise by sending Neighbor Solicitation messages to a smaller multicast address called the “solicited-node multicast address.”
The solicited-node multicast address is formed by appending the last-order 24 bits of an address (unicast or anycast) to the prefix ff02::1:ff00:0/104. Therefore, the format for this address is ff02:0:0:0:0:1:ffxx:xxxx, where “xx:xxxx” is the last-order 24-bit portion of the target address. For example, the solicited-node multicast address for the link-local address fe80::240b:2ac8:47c8:8e50 is ff02::1:ffc8:8e50.
For the solicited-node address to be useful in address resolution, it means that when a node’s interface is configured with an IPv6 address, that node must join the solicited-node multicast address group for that interface so that it can receive solicitation messages.
Note: A node (host or router) must also join the all-nodes multicast addresses (ff01::1 and ff02:1) and other multicast addresses of all groups the host belongs to. In addition, routers must also join the all-routers multicast addresses (ff01:2, ff02:2, and ff05:2).
By sending Neighbor Solicitation messages to the solicited-node multicast address, only a few hosts (those with interface addresses that have the same low-order 24-bit interface ID) will receive those messages, thereby reducing network disturbance, unlike ARP. Going back to our scenario therefore, we can see why the solicited-node multicast address for fe80::2 (fe80:0000:0000:0000:0000:0000:0000:0002) is ff02::1:ff00:2 (ff02::1:ff00:0002).
Finally, we move to the data-link layer.
The source address is the MAC address of R1′s Fa0/0 interface. However, the destination address is 33:33:ff:00:00:02. This is the Ethernet multicast MAC address of the destination address—in this case, the destination address is the solicited-node multicast address.
The Ethernet multicast MAC address is formed by appending the low-order 32 bits of the destination address to “33:33:”. Therefore, the Ethernet multicast MAC address for ff02::1:ff00:0002 is 33:33:ff:00:00:02.
Let’s stop here for now because we have already spoken about so many new concepts. We will recap the things we have talked about on address resolution:
It uses two messages: Neighbor solicitation and neighbor advertisement messages.
The target address in the neighbor solicitation message is the IP address to be resolved.
The destination IP address in the IPv6 header for a neighbor solicitation message (during address resolution) is the solicited-node multicast address of the target address.
The solicited-node multicast address is derived by appending the low-order 24 bits of a unicast/anycast address to the prefix ff02::1:ff00:0/104.
The destination MAC address of the Ethernet frame is formed by appending the low-order 32 bits of the destination IP address to “33:33:”.
This brings us to the end of this article, where we have been introduced to the neighbor discovery protocol. We have highlighted the nine functions performed by this protocol and we have also mentioned the five ICMP packet types it uses. We then went on to look at the address resolution function of ND where we discussed the Neighbor Solicitation message in detail.
In the next article, we will conclude with our discussion on address resolution. I hope you have found this article insightful.
References and Further reading
RFC 4861: Neighbor Discovery for IP version 6 (IPv6): http://tools.ietf.org/html/rfc4861
RFC 4291: IP Version 6 Addressing Architecture: http://tools.ietf.org/html/rfc4291
So far in this series, we have looked at the features of IPv6, IPv6 addressing, and the structures of IPv6 headers and packets. In this article, we will be looking at a protocol that is important to the working of IPv6—ICMPv6.
Introduction to ICMPv6
ICMPv6 is similar to ICMP for IPv4, except that ICMPv6 has added functionality and implements some changes that are necessary for the operation of IPv6. Like ICMP for IPv4, ICMPv6 provides error reporting (e.g., destination unreachable) and network diagnostic functions (e.g., ping). Also, ICMPv6 provides a foundation for other IPv6 operations, such as neighbor discovery (ND), which we will look at in future articles.
ICMPv6 Message Structure
The general format of ICMPv6 messages is similar to that of ICMP for IPv4. As we saw in the previous article, an ICMP message will be preceded by an IPv6 header and IPv6 extension headers if available and the Next Header value for an ICMP message will be 58. The figure below shows the Wireshark capture we used in the previous article:
As described in RFC 4443, the general structure for ICMPv6 messages is shown below:
The Type field defines the type of message, e.g., Destination Unreachable or Echo Reply. TheCode field may be used to add granularity to a particular message type; for example, the reason why a destination is unreachable. The Checksum field is used to check that the integrity of the ICMPv6 message and parts of the IPv6 header is preserved. Finally, the Message Body will vary depending on the ICMPv6 message type.
ICMPv6 Message Types
Let’s consider the Type field in the ICMPv6 general message structure above. Notice that it is made up of 8 bits, therefore you have a range of 00000000 (0 in decimal) to 11111111 (255 in decimal). Unlike ICMP for IPv4, which had “scattered” message types, ICMPv6 message types are divided into two groups:
Error messages—These messages have “0″ in the high-order bit of Type field; therefore, error messages are in the range of 00000000 (0) to 01111111 (127).
Informational messages—These message types have “1″ in the high-order bit of the Type field; therefore informational messages are in the range of 10000000 (128) to 11111111 (255).
ICMPv6 Error Messages
Currently, there are four ICMPv6 error messages that have been assigned, i.e., type 1 to type 4. Also, type 0 is reserved; type 100 and type 101 have been assigned for private experimentation; and type 127 has been reserved for possible future expansion of ICMPv6 error messages. We will now consider the type 1 to 4 error messages.
Type 1—Destination Unreachable
A Destination Unreachable message is generated when a packet cannot be delivered to the destination address. The ICMPv6 destination unreachable message has the following structure:
The Type field will have a value of 1. Also, because there are several reasons why a packet may not be deliverable, there are various values for the Code field in this message as shown in the table below:
Let’s take a look at a Destination Unreachable message in Wireshark. I have applied an access list to filter ping packets to fe80::2; therefore, from our table, the code should be 1 as shown below.
Type 2—Packet Too Big
The Packet Too Big message is generated in response to a packet that cannot be sent because the packet size exceeds the MTU of the outgoing link. This message is especially useful for the path MTU discovery process.
The Type field is set to 2 and the Code field is set to 0. The MTU field contains the maximum transmission unit of the outgoing link.
Type 3—Time Exceeded
A time exceeded message is sent when either the hop limit of a packet is 0 (upon receipt or after decrementing) or there is a timeout during fragment reassembly.
The Type field is set to 3, while the Code field can be either 0 (hop limit exceeded) or 1 (fragment reassembly timeout exceeded).
Type 4—Parameter Problem
The ICMPv6 message is sent when there is a problem with the IPv6 header or IPv6 extension header and further processing of the IPv6 packet cannot take place. For example, if “144″ is found in the Next Header field, this message will be generated because “144″ is not currently assigned to any protocol.
The Type field is set to 4, while the Code field can have a value between 0 and 3, as shown in the table below. The Pointer field gives information about the part of the IPv6 packet that had issues.
ICMPv6 Informational Messages
There are about 19 ICMPv6 informational messages that have been assigned, but we will be focusing on two common informational messages—Echo Reply and Echo Request.
Type 128- Echo Request and Type 129- Echo Reply
I have grouped these two messages together because they have a similar structure. The major difference is in the Type field: Echo Request has a type value of 128 and Echo Reply has a type value of 129.
Side talk: These type values for Echo Request and Echo Reply are finally logical. I used to wonder in ICMP for IPv4 why Echo Request, which comes first, would have a type value (8) greater than Echo Reply, which comes later (0).
The Identifier and Sequence Number fields help in matching corresponding echo replies to echo requests. For example, look at the Wireshark capture below, which shows the ping (echo request and reply) between fe80::1 and fe80::2; notice that the Identifier is the same (0x13a0) while theSequence Number increases (from 0 to 4). It shows that it is the same ping session but with 5 packets, i.e., the default repeat of ping on Cisco is 5.
This brings us to the end of this article on ICMPv6, in which we have looked at the general structure of ICMPv6 messages and also discussed the four error messages and two informational messages of ICMPv6. We will see still more of this protocol in other articles, but this is good enough for an introduction.
In the next article, we will begin discussing the neighbor discovery (ND) process of IPv6. I hope you have found this article insightful.
References and Further Reading
RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification: http://tools.ietf.org/html/rfc4443
Internet Control Message Protocol version 6 (ICMPv6) Parameters:http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml
RFC 792: Internet Control Message Protocol: http://tools.ietf.org/html/rfc792
Welcome to the fifth article in the IPv6 series. In past articles, we have looked at IPv6 address types, the IPv6 scoped address architecture and, most recently, interface identifiers for unicast addresses. In this article, we will consider the structure of an IPv6 packet and also look at the IPv6 header and how it compares to the IPv4 header.
IPv4 and IPv6 Packet Structures
From our IPv4 knowledge, we are familiar with the concept of encapsulation, in which each lower-level OSI layer takes the data passed down from higher layers of the OSI model and encapsulates it in its own format, including a header (and sometimes a footer). At the IP (network) layer, we call this message an IP packet or IP datagram. The general format of an IPv4 packet is as shown below:
The IP header is added at the IP layer and contains information such as the source and destination IP address, while the payload contains the upper-layer protocol data unit (i.e., the upper-layer header + upper-layer payload). Stemming from this format, the IPv6 packet is also similar except that the Payload portion is made up of upper-layer protocol data and IPv6 extension headers if available.
We will talk about IPv6 extension headers in a later section of this article, but keep in mind that an IPv6 packet may not contain an IPv6 extension header, effectively making the structure of that IPv6 packet similar to that of an IPv4 packet.
IPv4 and IPv6 Headers
As usual, let us begin with what we are familiar with. According to the RFC on IPv4, the IPv4 header is shown below:
Let’s briefly highlight what each field is about, because it will help in our understanding of the IPv6 header:
Version—Identifies the format of the header. For IPv4, this value will be 4. As we will see, the value will be 6 for IPv6.
IHL—This stands for Internet header length. Remember that, because of IP options, the IPv4 header does not have a fixed length. The minimum length is 20 bytes and the maximum length is 60 bytes.
Type of Service—This has been renamed the differentiated services field and it finds its use in quality of service (QoS).
Total Length—Entire length of the IPv4 packet, i.e., the header plus payload.
Identification—Helps in reassembly of fragmented packets.
Flags—Conveys information about fragmentation.
Fragment Offset—Indicates the position of a fragment in the payload.
Time to Live (TTL)—Specifies the maximum lifetime of a packet as it traverses links.
Protocol—Indicates the upper-layer protocol, e.g., TCP (6), ICMP (1).
Header Checksum—Ensures integrity of the IPv4 header. The payload is not included in the checksum calculation.
Source Address—Address of sending host.
Destination Address—Address of recipient.
Options—Variable length field that carries IPv4 options information, such as loose source routing.
Padding—Used to ensure that the header is a multiple of 32 bits.
Let’s look at an example packet (telnet session) captured through Wireshark.
The first thing you will notice is the concept of encapsulation that I mentioned above, i.e., the TCP segment is encapsulated in the IP packet, which is encapsulated in an Ethernet frame, and so on. Then, if we look at the IPv4 portion, we will see all the fields we discussed above, although there are no options (or padding) specified in this packet.
We can now move on to the IPv6 header. As I mentioned in the introductory article, the IPv6 header is much simpler than the IPv4 header even though it is twice the (minimum) size of an IPv4 header. According to RFC 2460, the main IPv6 header format is as shown below:
Let’s also highlight the fields in the IPv6 header as we did for IPv4:
Version—The same as in IPv4 except that it has a value of 6.
Traffic Class—Similar functionality as the differentiated services (ToS) field.
Flow Label—New to IPv6, this allows the source to identify that a packet belongs to a sequence of packets (i.e., flow) that require special handling by the router
Payload Length—This is similar to the Total Length field in the IPv4 header except that it specifies only the length of the payload, i.e., the IPv6 extension headers (if any) + upper-layer PDU.
Next Header—Uses the same values as the Protocol field in the IPv4 header. It identifies the type of header after the IPv6 header, i.e., an IPv6 extension header or an upper-layer protocol (e.g., TCP, UDP).
Hop Limit—Similar to the TTL field in the IPv4 header. The TTL field initially related to time in theory but, as we know, practical implementations used TTL as hop counts. This is why the field was renamed in IPv6.
Source Address—128-bit IPv6 address of the sender.
Destination Address—128-bit IPv6 address (unicast, anycast, or multicast) of the destination.
Let’s now try to compare the IPv4 and IPv6 headers.
Looking at the IPv6 header, the first thing you notice is that there are only 8 fields compared to the 14 fields in the IPv4 header; thus it is simpler.
There is no header length field in the IPv6 header because it has a fixed value of 40 bytes.
All fragmentation fields in the IPv4 header have been removed completely from the IPv6 header. They have been moved to an IPv6 extension header.
The header checksum field has also been removed from the IPv6 header.
As highlighted above, there is a new field in IPv6: Flow Label.
Finally, all options have been moved away from the main IPv6 header to IPv6 extension headers.
IPv6 Extension Headers
All through this article, I have mentioned the IPv6 Extension headers, so let’s talk about them now. In IPv4, if options are present in the IP header, all intermediate routers must also process them, thereby slowing down packet forwarding. In IPv6, all options have been moved to the IPv6 extension headers and intermediate routers do not need to process these headers (with the exception of the hop-by-hop options header). This speeds up the IPv6 header processing and also the packet forwarding.
There are six IPv6 extension headers that must be supported by all implementations as defined by RFC 2460:
Hop-by-hop options header
Routing (Type 0) header
Destination options header
Encapsulating security payload header
Hint: We are already familiar with the authentication header (AH) and encapsulating security payload Header (ESP) from IPsec.
An IPv6 packet may or may not include any of these IPv6 Extension headers the same way an IPv4 packet may or may not have options specified in the IPv4 header.
We can also look at a Wireshark capture of a ping (ICMPv6) between two IPv6 hosts and see the fields in the IPv6 header.
Notice that the Next Header field in the IPv6 packet shown above contains the value “58,” which is the protocol number of ICMPv6. The table below shows common values (in decimal) that can be found in the Next Header field of an IPv6 header.
Let us end this article with an example of the Next Header field values.
Using the Next header value table above, we can fill in the values for what the next header field will be in this diagram:
Below is a real capture of a fragmented ping between two hosts. Notice the IPv6 Fragment Headerand also Next Header values as discussed above.
In this article, we have looked at the packet and header structures for IPv6. We saw that IPv6 headers have a fixed length of 40 bytes and options from IPv4 have been moved to extension headers in IPv6.
In the next article, we will discuss ICMPv6, which plays a very important role in IPv6. I hope you have found this article insightful.
References and Further Reading
RFC 2460: Internet Protocol, Version 6 (IPv6) Specification: http://www.ietf.org/rfc/rfc2460.txt
RFC 791: Internet Protocol: http://www.ietf.org/rfc/rfc791.txt
Protocol Numbers: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
Internet Protocol Version 6 (IPv6) Parameters: http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
In this series, we have been looking at IPv6; so far, we have gone through an introduction to IPv6, its address types and, most recently, we looked at the IPv6 scoped address architecture. In this article, we will continue with our discussion of IPv6 addresses by looking at the interface identifier in the IPv6 unicast address format.
If you go back to the second article in this series (IPv6: Addressing), you will notice that a common field in the unicast address formats (link-local, global, etc.) is the interface ID. The interface ID uniquely identifies (within a subnet prefix) an interface on a link.
Let me explain using IPv4. Remember that an IPv4 address can be divided into two parts: Network ID (or network address) and Host ID (or host address), as shown below:
For example, in the subnet 192.168.10.0/24, there are usable IP addresses in the range of 192.168.10.1 and 192.168.10.254. If we take 192.168.10.1 as a focus, we can break it down as shown below:
Therefore, even if multiple hosts on that subnet have the same network ID, the host ID must be unique to each host within that subnet. Let’s now extend this to IPv6. The generic format of an IPv6 unicast address is:
Note: Generally, the Subnet Prefix = Prefix + Subnet ID. For example, for a global unicast address, the subnet prefix is made up of the global routing prefix and the subnet ID. For a link-local address, the subnet prefix is fe80::/10 + 54 bits of zeroes.
Comparing the IPv4 and IPv6 unicast address formats, we can say that the Host ID portion in IPv4 is equivalent to the Interface ID portion in IPv6. Interface ID more accurately reflects this portion of an address, since one host may have multiple interfaces.
Now that we understand what interface identifiers are, let’s move on to what the RFC has to say about them. According to RFC 4291, interface identifiers for all unicast addresses, except those that begin with binary 000, should be 64 bits long. These interface IDs should also be constructed using the modified EUI-64 format.
If you are familiar with 48-bit MAC addresses, then you are not far off from the EUI-64 format. MAC addresses are made up of two portions: The first (leftmost) 24 bits are organization-unique [i.e.,organizationally unique identifier (OUI)] and the last 24 bits are device-specific [i.e., specific to thenetwork interface controller (NIC)]. The EUI-64 format, which is 64 bits long, also has 24 bits in the OUI field but assigns the remaining 40 bits to the NIC portion, thus allowing a larger space for device identifiers. The general format of a EUI-64 address is as shown below:
The “u” bit is the universal/local (U/L) bit, which specifies whether the address is universally administered (u=0) or locally administered (u=1). The “g” bit is the individual/group (I/G), bit which specifies whether the address is a unicast address (g=0) or multicast address (g=1).
Modified EUI-64 Format
We have seen the EUI-64 format, but what is the modified EUI-64 format? It is actually very simple. The modified EUI-64 format is the EUI-64 format with the U/L bit inverted. Therefore, if the U/L bit is 0 in a EUI-64 address, it will be 1 in the modified EUI-64 format. Conversely, if the U/L bit is 1 in a EUI-64 address, it will be 0 in the modified EUI-64 format.
Let’s take an example. Consider a EUI-64 address of 00:43:78:E3:F4:52:13:6C. The U/L bit is the seventh bit (not hexadecimal character) counting from the left, i.e.:
00000000 01000011 01111000 …
To convert this address to the modified EUI-64 format, all we do is to invert that U/L bit, i.e.:
00000010 01000011 01111000 …
Therefore, the modified EUI-64 address will be 02:43:78:E3:F4:52:13:6C. That was simple enough, right?
Modified EUI-64 Format as IPv6 Unicast Address Interface ID
What does all this have to do with IPv6? Well, one of the benefits of IPv6 is automatic address configuration and, by using the modified EUI-64 format, nodes can configure unique addresses for themselves without requiring DHCP or manual assignment. Therefore, using our example above, the link-local address from that modified EUI-64 address will be fe80::243:78e3:f452:136c.
Note: This can be applied to all unicast addresses (with the exception already noted), given a subnet prefix. For example, given the global subnet prefix of 2001:db8::/64, the address from our example will be 2001:db8:: 243:78e3:f452:136c.
IEEE 802 48-Bit MAC Address to EUI-64 Format
The EUI-64 format is a newer format compared to the more familiar 48-bit IEEE 802 addresses and we still see these 48-bit addresses in use today. For example, my laptop’s LAN interface shown below has the 48-bit address:
Luckily, there is a way to convert from the IEEE 802 address format to the EUI-64 format. We do this by inserting hexadecimal characters “0xFF” and “0xFE” in the middle of the IEEE 802 addresses. Let’s use my LAN interface’s MAC address as an example. The diagram below shows the steps:
IEEE 802 48-Bit MAC Address to Modified EUI-64 Format
Now that we have converted our 48-bit address to EUI-64 format, we can easily convert it to modified EUI-64 format by inverting the U/L bit. Thus, we can say converting from IEEE 802 address to modified EUI-64 format is a two-step process:
Insert bits 11111111 11111110 (“FF:FE”) in the middle of the 48-bit address to convert it to EUI-64 format.
Invert the U/L bit in the new EUI-64 format address to convert it to Modified EUI-64 format.
Therefore, the modified EUI-64 format of my LAN’s 48-bit MAC address will be 76:86:7A:FF:FE:12:9F:D5.
Let’s see a real example of the interface ID of the link-local address of a Windows XP machine being generated from the IEEE 802 address.
Notice that the IEEE 802 address is 08:00:27:02:1C:88. By inserting “FF:FE” in the middle of that address, the EUI-64 format address becomes 08:00:27:FF:FE:02:1C:88. Now we will invert the U/L bit in this new EUI-64 format address to produce 0A:00:27:FF:FE:02:1C:88, which is the modified EUI-64 format. Therefore, the link-local address will be fe80::a00:27ff:fe02:1c88. As you can see, that is the address the node also derived.
Other Options for Determining Interface IDs
There are other ways to determine the interface IDs of unicast IPv6 addresses, two of which are:
Manual configuration—As we saw in the last article, I manually configured the link-local addresses for the interfaces on my GNS3 routers.
Randomly generated interface identifier—This can either be a temporary randomly generated interface ID, as defined in RFC 4941, or a permanent randomly generated interface ID, as used in newer versions of Windows, including Windows Server 2008, Windows 7, and so on.
My laptop is running Windows 8, so it uses the permanent randomly generated interface identifier method. Notice in the screenshot below that the link-local unicast address of my Wi-Fi interface is not derived from its MAC address.
You can disable this feature by using the netsh interface ipv6 set global randomizeidentifiers=disabled command from the command prompt.
This brings us to the end of this article, where we have seen how the interface ID portion of IPv6 unicast addresses are generated using the Modified EUI-64 format. We also highlighted other options for configuring these interface IDs.
In the next article, we will move on to the IPv6 packet and header format. I hope this article has been helpful.
References and Further Reading
RFC 4291: IP Version 6 Addressing Architecture: http://tools.ietf.org/html/rfc4291
EUI-64 Guidelines: http://standards.ieee.org/develop/regauth/tut/eui64.pdf
This year, the number of mobile-connected devices will exceed the world’s population. To survive the coming decade, most organizations will have to respond in some way to the rise of connected devices. As connected products, connected logistics, and connected phones become ubiquitous, they create value for users and risks for companies.
If you’re reading about the Internet of Things for the first time, here’s a short primer. But now that there’s widespread knowledge about the Internet of Things (IoT) — also known as the Machine to Machine internet (M2M) or the Industrial Internet (II) — we at consulting firm Undercurrent find that senior leaders at global organizations still struggle to articulate how it will meaningfully change their business, or shrug it off because they’re in the energy business, or the orange juice business, or name your 20th century business.
Winners will know they’re winning before losers find out they’re losing.
The pressures the IoT brings affect all types of organizations. For companies that make durable physical products it’s easy to imagine a digitally connected version. For companies that make consumables, the Internet of Things is slated to revolutionize logistics. For both, ubiquitous connected mobile devices are already changing commerce, workflow, and customer relationships.
Here are ten ways IoT will affect companies, and how companies can respond.
1. DO OR DIE, THE MARKET EXPECTS IT.
Over the next three years, every major manufacturer will have to include connectivity in its business product lines or logistics. Consumers will demand it soon, but Wall Street will demand it first. Companies like Tesla with their connected car or Amazon with their connected logistics are already trading above traditional valuations. Shareholders and analysts will evaluate companies based on their ability to integrate connectivity into their business and product lines.
2. MAKING PRODUCTS IS EASY, BUT PRODUCTION CHANGES TOO.
Manufacturers of consumer durables and equipment manufacturers will have to make connected products. CPG companies and grocers, will have to build in smart logistics. The new tech enables efficiency in managing production and distribution. Connected sensors monitor liquids, gases, and chemicals in real time. Route automation for moving things is on the horizon. Fleets of driverless trucks will soon become the standard.
3. THE RACE TO OWN THE PLATFORM STARTS WITH A PRODUCT FOCUS.
Competition will be dire, as most businesses will try to own the platform. While the tendency in big business is to build the platform first, every platform business starts off as a product business. Nest didn’t build a platform first, it built the best thermostat. To win, start with a hero product that conquers hearts and markets. This requires a radical focus on creating products and experiences that are beautiful, functional, and valuable to customers.
5. IOT IS AN ECOSYSTEM PLAY, AND ENABLES RELATIONSHIP GROWTH. IF YOU’RE IN THE CONSUMER BUSINESS, OWN THE HOME OR THE BODY.
In the future, consumers will buy new products based on how well they integrate with their smart home appliances or their health app. In June Apple released development kits for the smart home and the smart body. They’re enabling your competition and startups worldwide to create beautiful experiences for connected devices. When you go to Best Buy in a couple of years, you’ll ask if your new washing machine displays a discreet notification on your iTV. Being present in the home meaningfully also creates a commercial channel, and creates opportunities for great partnerships. You’d benefit if your fridge automatically re-ordered groceries from FreshDirect or Amazon Fresh, and so would the partners involved.
Connected equipment can sense and communicate a potential fault in any system before it creates a crisis. Such equipment can also lead to new efficiencies. For instance, a full milk tank can signal a smart truck to come pick up farm-fresh milk. Either way, a new service-driven model creates a reliable recurring revenue stream and protects your business from downstream challengers.
6. ALTERNATIVE BUSINESS MODELS WILL EMERGE.
When connected products become pervasive and communicate continuously with one another, marketplaces are created involving machines, not just people. Imagine a future where your fridge negotiates with the grid in real time to get you the best rate on power if it can wait a bit for the next cool cycle. Optimization provides quantifiable benefits, and value becomes apparent to your customers. Inside industry-leading businesses, the risk tolerance required to embrace new business models (think Innovator’s Dilemma) is paramount to making big leaps.
7. YOUR ORGANIZATION WILL NEED NEW SKILLS.
Creating these products or supply chain improvements will likely require you to focus on hiring more engineers, designers, and data scientists. Hardware is increasingly just software wrapped in plastic, and connected hardware is all about data. Your organization structure might have to adapt as well in order to move faster. You might have to shed some fat in other areas of the business. Teams will have to be leaner, smaller, and multi-disciplinary to get to market faster.
8. IN EMERGING MARKETS (AND BEYOND), MOBILE BECOMES THE DEFAULT INTERFACE.
In Kenya, more than two thirds of the adult population uses a mobile digital currency called M-Pesa; 25 percent or more of the country’s GNP flows through this parallel financial system. Most emerging markets already have pervasive mobile usage, and smartphone adoption is increasing in the rising mobile-first billion.
Besides being a requirement for products or solutions targeting developing markets, mobile is a natural interface for connected devices. I love Benedict Evans’ perspective on this: dumb sensors paired with smart phones become exponentially more valuable.
9. EXISTING ASSETS OR INFRASTRUCTURE BECOME MORE VALUABLE WHEN THEY’RE CONNECTED.
For many companies, perhaps the most overlooked asset class is the network of products and customers that an established business has already created in the world. Imagine you’ve been selling vacuum cleaners or street lamps for decades. Odds are, there are thousands or even millions of products exist in the world with your brand.
Similar to how cell tower businesses use their network of physical assets (towers) to create new revenue streams by leasing out spots on the towers, all companies with products out in the world have a potential base to integrate sensing, connectivity, and intelligence open new and exciting revenue streams. Imagine how valuable the street lamps on your highway become if they broadcasted up-to-the-second traffic updates.
10. MORE THAN ANYTHING, RECENT ADVANCEMENTS IN CONNECTIVITY, ARTIFICIAL INTELLIGENCE, AND ROBOTICS DEMAND A CHANGE IN STRATEGY.
Organizations will require a clearer visionary focus and purpose. The teams and skill-sets required for companies to succeed in the near future need to pair up with new ways of working. Leadership teams must find comfort in embracing unknowns and iterating towards solutions, and they have to empower their teams to move quickly into new markets and product spaces.
The change brought on by this new wave of connectivity will be will be subtle at times, but always valuable. What’s intimidating is that winners will know they’re winning long before losers find out they’re losing.
Estimote, the company behind a battery-powered Beacon that provides location and other information to smartphones, has shrunk its form factor into a sticker. It’s calling these stickers Nearables and it’s releasing a developer kit version today that offers 10 stickers for $99. My hope is with such a tool, developers can move beyond using Beacons merely as a way to promote goods in shops.
Estimote apparently has the same idea, because the video accompanying the product launch includes existing location apps such as using a sticker on your purse and then getting a notification as you walk too far away. You could also pop a sticker on your dog’s collar and get a similar notification if she runs away. In a future iteration, the Beacon sticker might also be able to store ownership info, or even transmit your dog’s information to those around it also running the app if you trigger an alert.
That fits with the use cases offered by many of the Bluetooth trackers on the market, but other ideas in the video were more interesting, such as using a sticker to provide context about your presence in the home. Developers could use the stickers to build a better alarm clock app that knew you were in your bedroom, took in traffic information and your schedule and decided the optimal time to wake you up.
I’d like to use stickers build an app that reduces some of the noise provided by sensors in my home. For example, I used to have an open/close sensor on my liquor cabinet, that sent me a text if it opened (I have a child). I got a lot of texts. But if I popped an Estimote sticker on the cabinet as well, when my husband or I opened the cabinet the sticker would know it is us and could prevent the notification. Of course, then all my kid needs to do is steal my smartphone if she wanted to go on a bender undetected.
This is pretty exiting, and the price makes these close to disposable. I’d pay $100 a year (which is how long the battery inside lasts) to add stick-on presence to my home. As for disposal, though, it’s going to take a bit of work. The inside of each sticker packs a powerful dose of electronics, with a microcontroller, memory and radio on a single die and then an accelerometer and gyroscope on the board. Feeding power to the electronics is a Lithium ion battery.
Steve Cheney, Co-Founder and SVP of Business, at Estimote wrote me the following when I asked about disposal:
As far as disposing, they have a lithium battery cell so ideally they are disposed responsibly. They are encased in a silicon enclosure but it’s possible to cut this and remove the battery. Everything we use (like our current beacons) is super environmental friendly, these are manufactured by us, not by an ODM in Asia.<br />
While these stickers offer a lot of potential, and thanks to Apple, beacons are seemingly becoming a mainstream technology, I have seen similar efforts before. Back in 2008, Alcatel Lucent created a spin out offering RFID stickers called Tikitagthat offered similar promises. More recently, Norwegian firm ThinFilm has teamed up with partners to print out circuits that contain memory and NFC radios that can offer information. These printed electronics are designed to stick onto packaging and help track data about everything from equipment to food.
The Estimote stickers are not flat and are much too expensive for tracking food or low-end stuff, but as a way to offer cheap presence or detailed context about a high-value object, I’m intrigued.
Source: http://www.scribd.com/doc/235833595/lte -
Home : http://www.sharetechnote.com
Before the era when cell phones became permanently glued to our hands and our ears, walkie talkies were the fastest and most efficient way of communicating over a short distance. As mobile technology advanced both the devices and the service, field workers such as construction companies and police departments became synonymous with the chunky phones and scenarios depicted in the Nextel advertisements of the late 1990’s. After the demise of the original iDEN Nextel National Network just a short year ago, some may think that the “push-to-talk” movement is over, but that is far from the truth.
Not Your Father’s Push-to-Talk
Today’s push-to-talk functionality has expanded beyond the bulky boxes associated with walkie talkies, and instead is provisioned through applications running over the nation’s most advanced cellular networks. These apps can be downloaded to a variety of mobile devices, ranging from Samsung’s rugged Galaxy Rugby Pro to Apple’s sleek and sexy iPhone, as well as across operating systems including Android, iOS and BlackBerry.
So what can push-to-talk do for your business? Think of it as a voice text message and it’s easy to see the benefits the real-time collaboration tool can provide. If you are part of a group, push-to-talk can provide quick and easy communication at the push of a button, with no dialing involved. It provides a faster connection across devices, offers close to hands-free operation and conveys a sense of urgency that most text messages cannot.
Imagine you’re a visiting nurse and need to report back to your superior from a patient’s bedside. With one hand you are able to connect through push-to-talk, leaving your other hand free to check the patient’s pulse or program a machine. The same goes for an IT team fanned out across a corporate campus during a service outage. While working to fix the problem, push-to-talk allows the team to connect with their peers seamlessly.
For anyone who has been along for the ride as mobile devices changed from the Nokia bricks of past, to flip phones and now touch screens, learning how to use the new technology can be a tricky and extends the learning curve. Push-to-talk requires minimal training, allowing even the least tech-savvy employee to master the communication tool in seconds.
The Evolution of Push-to-Talk Services
In 1996, Nextel launched its iDEN service, followed by the major cellular carriers coming to market with the first cellular push-to-talk solutions in 2003. Two years later, Sprint acquired Nextel, inheriting nearly nine million push-to-talk customers who had to migrate to Sprint’s CDMA Direct Connect network. By June 2013, quality-of-service issues, the burden of maintaining multiple networks and the need for spectrum to offer more profitable and newer data services ultimately led to the shutdown of the Nextel push-to-talk network.
While some companies were able to move forward without a glitch, others that relied heavily on push-to-talk services found themselves in a tough situation. Some companies had to accept the situation and move on, while others looked for a new option. Fortunately for the latter, the new push-to-talk app has provided the same level of connectivity with more advanced and reliable technology and service.
A New Generation of Enhanced Push-to-Talk
Push-to-talk has gone up and down over the last decade, but with newer, more advanced services now available for traditional and non-traditional apps it’s definitely on an upswing. When properly deployed, this “voice text message” service can increase efficiency, save time and enhance the productivity of any workforce. Forget about the walkie talkies of lore, companies should consider adding push-to-talk solutions to meet their total communications needs.
Or maybe not. A look at the wireless industry now makes the doomsayers look more like soothsayers.
Mobile carriers have begun to give the world a picture of what a net neutrality-free Internet could look like. Wireless companies have slowly but surely begun to roll out plans that favor certain content providers or entirely limit access to particular sites and apps.
Regulation of this activity is tricky. It is an area that FCC chairman Tom Wheeler has said is under supervision but “should not be prohibited out of hand.” Wheeler has not been shy about going after companies for limiting consumers’ access, but has little legal basis for going after the deals made between companies. (The FCC declined to comment for this story.)
Here’s a rundown of what T-Mobile, AT&T and Sprint have been up to:
As these deals pile up, a less-than-rosy picture of the future of mobile Internet begins to emerge. Fred Wilson, a prominent venture capitalist, recently took to his blog to discuss how these plans can seem advantageous. He focused on “zero rating,” in which companies pay providers so that their content does not count against data plans.
“The pernicious thing about zero rating is that it is marketed as a consumer-friendly offering by the mobile carrier — ‘we are not charging you for data when you are on Spotify,'” he wrote in a post.
“But what all of this zero rating activity is setting up is a mobile internet that looks a lot more like cable TV than our wide open Internet,” he wrote. “Soon, a startup will have to negotiate a zero rating plan before launching because mobile app customers will be trained to only use apps that are zero rated on their network.”
It’s not that wireless Internet might end up becoming tiered for everyone, but freedom could become an expensive feature of smartphone plans.
It’s not that wireless Internet might end up becoming tiered for everyone, but freedom could become an expensive feature of smartphone plans.
Mobile broadband is regarded by the FCC differently from “fixed” broadband, which is Internet service used by devices at certain endpoints, usually computers. The most important distinction comes from the 2010 Open Internet Order, which detailed that mobile had to abide by transparency requirements but not other rules that helped ensure net neutrality for fixed broadband.
The order meant that wireless companies like AT&T, Verizon Wireless, T-Mobile and Sprint could strike deals with companies that would prioritize certain content.
This might not have seemed as big of a deal in 2010, as mobile data usage remained a fraction of the larger Internet. That changed as smartphones matured, networks grew faster and more companies tailored content for the mobile experience.
To capitalize on this growth, mobile broadband providers have rolled out new data plans that put caps on usage and charge for overages. Many plans once offered limited voice minutes and text messages with unlimited data. That has now flipped, with data capped and voice and text an unlimited afterthought.
Data caps are not unique to wireless companies, and are on their way to a broader landline market. Comcast has been testing such plans and its chief executive has already said “usage-based billing” is on its way.
The combination of data caps and sponsored content deals suddenly make the dystopian Internet future more believable. With Internet consumption pushing more into mobile, the lack of rules ensuring equal access is providing some idea of what might happen if the FCC is unable to enforce net neutrality rules.
The result, unfortunately enough, looks a lot like a nightmare dreamt up by the most paranoid net neutrality advocates.
Have something to add to this story? Share it in the comments.