标签: ipv6

引言 IPv6是互联网升级演进的必然趋势、网络技术创新的重要方向、网络强国建设的基础支撑。近些年，随着我国大力推动IPv6规模部署和应用，目前中国的IPv6渗透率已超过70%。 对于车载以太网来说，目前IPv4是车载IP通信的主流协议，但随着车辆的智能化、网联化程度不断提高，IPv6协议应用在车载以太网是一种未来趋势。 那IPv6是什么呢，它包含哪些内容呢，带着这些疑问本文将带领读者认识IPv6。对于引言提到的IPv4协议，有想了解的读者可以阅读上一篇文章《IPv4协议——互联网通信协议第四版》。 为什么需要IPv6协议 IPv6协议（Internet Protocol version 6）——互联网通信协议第六版，是互联网工程任务组（ IETF ）设计的用于替代 IPv4 的下一代IP协议。IPv6的出现和普及可以有效地解决IPv4地址枯竭问题。 为什么没有IPv5 IPv5曾被提出并设计用于多媒体传输，‌但由于其地址限制、‌缺乏广泛标准化和支持以及实际应用中存在的问题，‌IPv5并没有成为广泛应用的互联网协议。‌相反，‌IPv6作为更先进的协议，‌成功地满足了未来互联网的需求，‌成为了下一代互联网协议的标准。 IPv6地址表示方法 IPv6地址长度为128位，每16位地址为一组，通常分为8组，每组十六进制数间用冒号分隔，例如：ABCD:EF01:2345:6789:ABCD:EF01:2345:6789。 RFC2373标准中规定了IPv6的规范文本表示形式： 1. 每组中的前导“0”都可以省略，2001:0DB8:0000:0023:0008:0800:200C:417A可写为2001:DB8:0:23:8:800:200C:417A。 2. 地址中包含的连续两个或多个均为0的组，可以用双冒号“::”来代替，FF01:0:0:0:0:0:0:1101可写为FF01::1101。 3. 在一个IPv6地址中只能使用一次双冒号“::”，否则当计算机将压缩后的地址恢复成128位时，无法确定每个“::”代表0的个数。 IPv6地址类型 IPv6协议主要定义了三种地址类型：单播地址、组播地址和任播地址。与IPv4地址类型比较，IPv6新增了任播地址，取消了IPv4的广播地址。但在IPv6协议中，广播功能是通过组播来完成的。 单播地址 用来唯一标识一个接口，类似于IPv4中的单播地址。发送到单播地址的数据 报文 将被传送给此地址所标识的一个接口。 目前常用的单播地址有：未指定地址、环回地址、链路本地地址、唯一本地地址、全局单播地址。 1. 未指定地址（0:0:0:0:0:0:0:0/128或::/128）：仅用于表示某个地址不存在，等同于IPv4未指定地址0.0.0.0。未指定地址通常被用做尝试验证暂定地址唯一性数据包的源地址，并且永远不会指派给某个接口或被用做目标地址。 2. 环回地址（0:0:0:0:0:0:0:1/128或::1/128）：用于标识环回接口，允许节点将数据包发送给自己，等同于IPv4环回地址127.0.0.1。 3. 链路本地地址（FE80::/10）：仅用于单个链路（链路层不能跨VLAN），不能在不同子网中路由。 4. 唯一本地地址（FC00::/7、FD00::/8和FC00::/8）：唯一本地地址是本地全局的，它应用于本地通信，但不通过Internet路由，将其范围限制为组织的边界。 5. 全局单播地址：等同于IPv4中的公网地址，可以在IPv6 Internet上进行全局路由和访问。这种地址类型允许路由前缀的聚合，从而限制了全球路由表项的数量。 组播地址 用来标识一组接口（通常这组接口属于不同的节点），类似于IPv4中的组播地址。发送到组播地址的数据报文被传送给此地址所标识的所有接口。 IPv6组播地址的最高的8位固定为1111 1111，如FF00::/8。 任播地址 用来标识一组接口（通常这组接口属于不同的节点）。发送到任播地址的数据报文被传送给此地址所标识的一组接口中距离源节点最近（根据使用的 路由协议 进行定义）的一个接口。 一个任播地址必须不能用作IPv6数据包的源地址，也不能分配给IPv6主机，仅可以分配给IPv6路由器。 IPv6报头格式 IPv6报文分为IPv6报头（长度固定为40字节）、扩展报头和数据部分。其中，扩展报头是可选报头，可能存在0个、1个或多个。 IPv6报头结构如下图所示： -版本号（Version） 4bits，表示当前IP协议版本号，此处协议版本号为IPv6(6)。 -流量等级（Traffic Class） 8bits，用于识别和区分IPv6报文的不同类别或优先级。 -流标签（Flow Label） 20bits，用来标识同一个流里面的报文，对于不支持Flow Label字段功能的主机或路由器，需要在发起报文时将该字段设置为零，在转发报文时不修改该字段，在接收报文时忽略该字段。 -载荷长度（Payload Length） 16bits，IPv6有效载荷长度，包含扩展报头和数据部分的长度。 -下一报头（Next Header） 8bits，标识紧跟在IPv6报头后的报头类型。 -跳数限制（Hop Limit） 8bits，该字段类似于IPv4中的 TTL ，每次转发跳数减一，该字段达到0时包将会被丢弃。 -源地址（Source Address） 128bits，标识该IPv6报文的源地址。 -目标地址（Destination Address） 128bits，标识该IPv6报文的目标地址。 IPv6扩展报头 IPv6报文中不再有“选项”字段，而是通过“下一报头”字段配合IPv6扩展报头来实现选项的功能。使用扩展头时，将在IPv6报文下一报头字段表明首个扩展报头的类型，再根据该类型对扩展报头进行读取与处理。每个扩展报头同样包含下一报头字段，若接下来有其他扩展报头，即在该字段中继续标明接下来的扩展报头的类型，从而达到添加连续多个扩展报头的目的。在最后一个扩展报头的下一报头字段中，则标明该报文上层协议的类型，用以读取上层协议数据。 IPv6扩展头使用示例 使用协议 地址配置协议 IPv6使用两种地址自动配置协议，分别为无状态地址自动配置协议（ SLAAC ）和IPv6动态主机配置协议（ DHCPv6 ）。SLAAC不需要服务器对地址进行管理，主机直接根据网络中的路由器通告信息与本机 MAC地址 结合计算出本机IPv6地址，实现地址自动配置；DHCPv6由DHCPv6服务器管理 地址池 ，用户主机从服务器请求并获取IPv6地址及其他信息，达到地址自动配置的目的。 1. 无状态地址自动配置 无状态地址自动配置的核心是不需要额外的服务器管理地址状态，主机可自行计算地址进行地址自动配置，包括4个基本步骤： （1）链路本地地址配置。主机计算本地地址。 （2）重复地址检测，确定当前地址唯一。 （3）全局前缀获取，主机计算全局地址。 （4）前缀重新编址，主机改变全局地址。 2. IPv6动态主机配置协议 IPv6动态主机配置协议DHCPv6是由IPv4场景下的 DHCP 发展而来。客户端通过向DHCP服务器发出申请来获取本机IP地址并进行自动配置，DHCP服务器负责管理并维护地址池以及地址与客户端的映射信息。 DHCPv6在DHCP的基础上，进行了一定的改进与扩充。其中包含3种角色：DHCPv6客户端，用于动态获取IPv6地址、IPv6前缀或其他网络配置参数；DHCPv6服务器，负责为DHCPv6客户端分配IPv6地址、IPv6前缀和其他配置参数；DHCPv6中继，它是一个转发设备。 路由协议 与IPv4相同，IPv6路由协议同样分成 内部网关协议 （IGP）与 外部网关协议 （EGP），其中IGP包括由RIP变化而来的RIPng，由OSPF变化而来的OSPFv3，以及IS-IS协议变化而来的IS-ISv6。EGP则主要是由BGP变化而来的BGP4+。本文不对IPv6的路由协议作更进一步展开说明，如果各位对文章中提到的IPv6路由协议内容感兴趣的，可以去网上搜索相关知识点学习拓展。 优势特点 与IPv4相比，IPv6具有以下几个优势： IPv6具有更大的地址空间。IPv4中规定 IP地址 长度为32，最大地址个数为232；而IPv6中IP地址的长度为128，即最大地址个数为2128。与32位地址空间相比，其地址空间增加了2128-232个。 IPv6使用更小的路由表。IPv6的地址分配一开始就遵循聚类的原则，这使得路由器能在路由表中用一条记录表示一片子网，大大减小了路由器中路由表的长度，提高了路由器转发数据包的速度。 IPv6增加了增强的组播支持以及对流的控制，这使得网络上的多媒体应用有了长足发展的机会，为服务质量QoS（Quality of Service）控制提供了良好的网络平台。 IPv6加入了对自动配置的支持。这是对DHCP协议的改进和扩展，使得网络（尤其是局域网）的管理更加方便和快捷。 IPv6具有更高的安全性。在使用IPv6网络中，用户可以对网络层的数据进行加密并对IP报文进行校验，在IPv6中的加密与鉴别选项提供了分组的保密性与完整性。极大地增强了网络的安全性。 允许扩充。如果新的技术或应用需要时，IPv6允许协议进行扩充。 更好的头部格式。IPv6使用新的头部格式，其选项与基本头部分开，如果需要，可将选项插入到基本头部与上层数据之间。这就简化和加速了路由选择过程，因为大多数的选项不需要由路由选择。 IPv6的发展与前景 “第三届中国IPv6创新发展大会”指出，当前全球互联网正处在从IPv4向IPv6过渡的关键时期，作为新一代互联网协议，IPv6具有更加广阔的网络地址空间和更高的安全性，为物联网、大数据、云计算等新兴技术发展提供坚实的支撑，是全球公认的下一代互联网商业应用的解决方案。加快推进IPv6的部署和应用，对于打造竞争新优势，加快形成新质生产力，推动网络强国和数字中国建设具有重要意义。当前我国IPv6用户渗透率已超过70%，近年来推动IPv6+已显现其潜力。 总结 IPv6作为替代IPv4的下一代协议，虽然目前还未全面普及，但随着技术的发展和用户需求的增长，全面普及是不可避免的趋势。所以提前认识和了解IPv6能够帮助我们从容应对未来IPv6所带来的挑战。 北汇信息是一家专注于汽车电子测试领域的企业，对车载以太网测试有着丰富经验，并可提供相关培训、咨询服务以及测试解决方案，帮助汽车制造商和零部件供应商确保其车载以太网系统的可靠性和安全性。如果需要具体的测试服务或了解更多信息，欢迎大家来联系我们。 参考文献： 【1】《RFC 2460》 【2】《RFC 2373》

尽管从2009年到2015年IPv6地址的采用速度很慢，但近年来却加速了。截至2019年，26%的用户通过IPv6地址访问Google。恒讯科技的独立服务器都分配有一个IPv6地址的 /64块（1 个子网），即18、446、744、073、709、551、616个地址。在本文中，小编将分析在Ubuntu怎么配置ipv6地址？这里分享两个操作方法： 一、在Ubuntu 16.04中配置IPv6地址 首先，使用ip命令列出网络接口名称：ip地址 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0。 0.1/8 范围主机 lo valid_lft 永远 preferred_lft 永远 inet6 ::1/128 范围主机 valid_lft 永远 preferred_lft 永远 2: eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 链接/以太 00:00:5e:00:53:3a brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc noop state DOWN group default qlen 1000 链接/以太 00:00:5e:00:53:3b brd ff:ff:ff:ff:ff:ff 从输出中，记下公共接口名称，对我们来说是eth0，因为您将在下一步中需要它。 接下来，/etc/network/interfaces使用您选择的文本编辑器打开文件： sudo vi /etc/network/interfaces 然后，将以下内容添加到文件中： iface eth0 inet6 静态 地址2001:db8:100:15a::1 网络掩码 64 dns-nameservers 2001:41d0:3:163::1 post-up sleep 5; /sbin/ip -family inet6 route add 2001:db8:100:1ff:ff:ff:ff:ff dev eth0 post-up sleep 5; /sbin/ip -family inet6 route add default via 2001:db8:100:1ff:ff:ff:ff:ff pre-down /sbin/ip -family inet6 route del default via 2001:db8:100:1ff:ff: ff:ff:ff pre-down /sbin/ip -family inet6 route del 2001:db8:100:1ff:ff:ff:ff:ff dev eth0 如果接口的状态为DOWN，则使用ip命令将其启动： ip link设置eth0 最后，使用systemctl命令重启网络服务： sudo systemctl 重启网络 使用该ping6命令测试系统是否可以使用 IPv6 地址进行通信。我们将使用解析为 example.com 的 IPv6 地址： ping6 2606:2800:220:1:248:1893:25c8:1946 二、在Ubuntu 18.04+中配置IPv6地址 Ubuntu的开发者Canonical从17.x 版本开始使用Netplan进行易于使用的网络配置。systemd.network 但是，在撰写本文时，Netplan和（管理网络的系统服务）之间存在IPv6配置的一个已知问题 。本质上，IPv6 配置没有从Netplan正确中继到systemd.network. 因此，我们将使用配置IPv6地址systemd.network，完全绕过Netplan。 首先，使用ip命令列出网络接口名称： ip地址 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0。 0.1/8 范围主机 lo valid_lft 永远 preferred_lft 永远 inet6 ::1/128 范围主机 valid_lft 永远 preferred_lft 永远 2: eno1: mtu 1500 qdisc noop state DOWN group default qlen 1000 链接/以太 00:00:5e:00:53:3a brd ff:ff:ff:ff:ff:ff 3: eno2: mtu 1500 qdisc noop state DOWN group default qlen 1000 链接/以太 00:00:5e:00:53:3b brd ff:ff:ff:ff:ff:ff 从输出中，记下公共接口名称，对我们来说是eno1，因为您将在下一步中需要它。 接下来， 使用您选择的文本编辑器在 目录中创建文件： 10-eno1.network/etc/systemd/network sudo vi /etc/systemd/network/10-eno1.network 然后，将以下内容添加到文件中： 名称= eno1 DHCP=ipv4 网关= 2001:db8:100:1ff:ff:ff:ff:ff DNS= 2001:41d0:3:163::1 地址= 2001:db8:100:15a::1 /64 目的地= 2001:db8:100:1ff:ff:ff:ff:ff 范围=链接 最后，使用systemctl命令重新启动网络服务，应用配置，并调出界面。 sudo systemctl重启systemd-networkd 使用该ping6命令测试系统是否可以使用 IPv6 地址进行通信。我们将使用解析为example.com 的IPv6地址： ping6 2606:2800:220:1:248:1893:25c8:1946 以上就是在Ubuntu怎么配置ipv6地址所需的步骤，希望能帮助到大家！

ip地址是服务器上最重要的存在，如果没有IP地址，就不能远程连接服务器，也不能在服务器上进行相应的业务。IP地址的作用也很大， IP地址是指互联网协议地址，即互联网之间相互通信的协议。每台电脑或服务器都是一个独立的IP，唯一且不可重复，如果把一台电脑或一台服务器看成一部手机，那么一个IP地址就相当于一部手机的电话号码。使用IP地址，您可以与其他IP地址进行通信。 那么使用服务器中的ipv4和ipv6地址有什么区别？而在未来的发展历程中，究竟是选择ipv4还是ipv6？下面小编就跟大家一起分析一下。 一、什么是ipv4？ ipv4的默认长度为32 位。有2*32-1个地址，所以ipv4有四段数字，一般不超过255。由于互联网的发展，对IP的需求也越来越大，如果IP地址的缺失会导致互联网发展缓慢。 二、什么是ipv6？ 面对互联网飞速发展的趋势，仅靠ipv4已无法满足人们的需求。现在，ipv6已经启动，ipv6的空间远大于ipv4的空间，ipv6使用128位地址长度。ipv6设计后，IP地址短缺的问题大大减少。而且还在一步步解决ipv4的问题，将ipv6发展到极致，ipv6是2*128-1个地址，解决了一些ipv4无法解决的问题。 三、服务器中的ipv4和ipv6地址之间的区别： Ipv4包括局域网IP和外网IP，外网IP和内网IP不能相互识别，而ipv6是私有IP地址，也是普通IP地址。ipv6的特点是，如果使用ipv6的计算机，该计算机可以相当于一台服务器。如果同一个ipv6的用户可以直接访问你电脑中的所有文件，但是同一个ipv4的用户不能，另外，ipv4是32位地址长度，ipv6是128位地址长度，这就是它们之间的区别。 四、选择ipv4还是选择ipv6？ 面对互联网飞速发展的今天，如果多人拥有一台或多台电脑，那么ipv4就无法满足了。我们可以推荐ipv6，因为ipv6的空间很大。 ipv6使用 128 位地址长度，而 ipv4使用 32 位地址长度。在使用中，ipv6可能比ipv4实用很多，小编可以建议使用ipv6。 总结：相信经过上面的介绍，大家对ipv4和ipv6的区别有了一定了解。小编推测如果互联网继续发展在这样以后可能会推出ipv10，空间更大，可以更好的满足需求。

Every time I reflect on the ubiquitously connected environment in which all of us and our ‘things’ now exist -- and the names we use to describe it -- I am reminded of a classic short story by science fiction writer Arthur C. Clarke: " The nine billion names of God ."       In it, two computer technicians are hired by the monks at a Tibetan lamasery who believe they have been assigned the task of listing all the names of God -- nine billion by their estimation -- after which the world will come to an end. For three centuries, the monks have been at this task, writing down by hand all the names they have found. They figure they have another 15,000 years to go unless they use modern technology. So the monks hire the technicians to set up a computer to automate the process. Having completed their assignment, the technicians are about to board an airplane to leave Tibet and -- you guessed it -- the lights in the sky blink off and the world ends.   If task instead were for the monks to write down the many names used in the past to describe what we now commonly call the "Internet of Things" and then write down all the meanings and interpretations of that term, I doubt the world would have come to an end, even in 15,000 years.   Our craziness about naming our connected computing environment may have begun in 1998, when the Internet Engineering Task Force (IETF) formalized IPv6 as the successor protocol to IPv4, which used 32-bit addresses and provided about 4.3 billion unique addresses to the TCP/IP protocols. It was determined that given population trends and the lowering costs of both personal computers and servers to within the price range of most households and small businesses, it was clear that IPv4 was going to run out of addresses soon.     IPv6, which uses a 128-bit address, allows about 3.4×10 38 addresses, or more than 7.9×10 28 times as many as IPv4, making it theoretically possible to assign not only every person in the world their own URL, but all their pets and personal things as well -- just about any ol’ “thing” that could be connected. The Internet of Things became popular with IPv6, perhaps due to the shock of that realization that we have driven ourselves crazy coming up with names for the new environment and the entities in it.   Internet 'appliances' Some of the names have included smart devices , netcentric computing devices , network computers , and ubiquitous or pervasive computing devices . Then there were a number of names that built on the definition of “appliance”, which is simply a machine designed to perform a specific function (i.e., kitchen appliances such as ovens and refrigerators).   For example, information appliances came into common use to describe such and connected devices, such as smartphones, which had moved far beyond their original function as a dedicated voice communications device to include a range of functions traditionally done on the home PC: writing, email, and viewing photos and videos. But once marketers got involved “information appliance” began to be used for almost any embedded device.   Another popular name, Internet appliances , met the same fate. That term originally described a dedicated device that made it possible for a non-techie to access specific internet services. But amongst the consumers and even the manufacturers, this term began to be confused with information appliances and was then conflated to describe smartphones.   Looking for some way out of this craziness, I looked for inspiration to physics, where phenomenon, devices, and systems are named after people who had a role in discovering a physical effect: Volts, Amperes, Ohms, Hall effect, Josephson junctions, and so on.   Another possibility I thought about suggesting was for the members of some IETF or other official working group to sit down and read Finnegan’s Wake by James Joyce and find a made-up name total devoid of previous intellectual history. That is where Nobel Prize winner Murray Gell-Mann found the word Quark , which he used as the name for a new fundamental particle that one of his papers on subatomic physics predicted.   One name I liked then and still do is Tier-0 devices . This term has a long history in computing, dating all the way back to mainframes in the '60s and '70s. The term derives from early mainframe/client/server designs , where Tier-3 machines were centralized mainframes and minis, Tier-2 were servers, and Tier-1 were desktop systems, originally smart and dumb terminals and later desktop computers, laptops and smartphones. The name Tier-0 was originally used to describe any computing device smaller than a desktop or smartphone with the main task of embedded processing of real-time events related to controlling devices. Then marketing got involved, and makers of PDAs, set-top boxes, video game consoles and cell phones used it to describe their offerings.   Beyond foolishness But now, in the new world of the Internet of Things, we are beyond all that foolishness, aren't we? Fat chance. Now, rather than a confusion of names what we have a multiple often contradictory definitions of what the Internet of Things is.   For the general public, and unfortunately for many journalists as well, even those covering electronics and software development, the broadest possible and most meaningless interpretation is used: if it is a thing and it is connected in any way to a network, Internet-enabled or not, it is an Internet of Things device.   The problem is the word thing. It is just a word we all use to describe any inanimate object, the ultimate in what screenwriters would call a high-concept description of an idea in a few succinct words, often to the point of obscuring any really meaningful information.   Originally, the term Internet of Things had specific meaning. I first came across it in the late '90s in reference to radio frequency ID tags, where the originators of that technology drew inspiration from IPv4 and its use of URL identifiers that were assigned to each server on the Internet. Their idea was to make it easier for companies to keep track of "things" -- packages, components, subsystems -- by attaching RFID tags to them, each with a unique number. Then in 2004, the term was broadened to include the 6LoWPAN wireless extension to IPv6 to describe the linkage of specific kinds of "things" to the Internet with unique URL identifiers. Usually these were embedded things: microcontrollers, sensors and systems in which communications were machine-to-machine in nature -- no humans need apply.       Now, in technical circles, the Internet of Things has come to imply a connected world in which all electronic things will be connected via IPv6’s TCP/IP protocol stack, with each identified by its own unique URL. But not everything will be so connected, for a variety of reasons. Even now, the IoT is beginning to fragment into many multiple subdomains: an industrial IoT, a building automation IoT, a defense and aeronautics IoT, and a consumer IoT -- each of them have about as much in common with each other as various sects of Christianity have to one another, which is often very little.   One reason for this segmentation -- and separation -- has to do with the TCP/IP protocol itself. Developed originally in a time when the concern was connecting computing systems operated by humans, its underlying assumptions were based on human reaction times and expectations. Because it was important to the humans using it, all TCP/IP does is guarantee delivery. It is not overly concerned with when delivery occurs. The segments of electronics that still fit comfortably within that definition are personal computers, smartphones, and such new wearable consumer IoT designs such as smart watches and health and fitness monitors, which assume the close interaction of things with humans.   But TCP/IP is basically asynchronous and is neither real-time nor deterministic, both of which are key requirements for many embedded things, particularly in the industrial segment. For others, such as in military/aerospace applications, the prime concern is security. There the idea of operating in an environment in which everything is connected without some exclusions is unacceptable. In automotive the problem is safety and how to operate in a "mixed criticality" environment in which systems with a high degree of safety requirements can work with systems -- most of them from consumer electronics -- which have no such requirements.   I suspect that such segmentation will continue, but all within under the same broad IoT umbrella, as meaningless and devoid of useful information as it is. It would be nice, though, if the electronics industry paid as much attention to standards for naming things as we do to the specifics of various standards we use. I think Skip Ashton, vice president of software at Silicon Labs, had it right when in a recent interview with Junko Yoshida he said it was important to be less focused on the Internet and more on the “things” it contains.   Ashton said that knowing intimately what "things" are supposed to do and how they think and behave will be the key to solving one of the IoT's most pressing issues: application layers. “Over the past 18 months, the industry has launched numerous consortia,” he said. “Every entity says it's targeting the 'interoperability' of things at home, but each is obviously concentrating primarily on its own interests.” But how do we eliminate that scattershot effort? One way is to come up with a common set of names and definitions. An IETF or IEEE standards group or procedure for names? But unless it was government mandated we would still be in a mess. How about doing what some industry groups and companies do, create a logo for the use of a term, such as “IoT Inside,” that a company could use on their products only if they met certain requirements? But all of this assumes that there is some sort of common desire to come up with a nomenclature that will be accepted and that actually means something. I don't think that exists. There is just too much invested right now on the marketing hype side in keeping things about the "Internet of Things" as vague and undefined as is possible for as long as possible, maybe even for the next 15,000 years.   We still have time to sort things out, though. Maybe not 15,000 years, but at least two or three hundred years given the current deployment rate of IPv6. IPv4 is still carrying more than 96% of Internet traffic worldwide as of May, 2014. And more than 15 years after it was formalized, only 4 percent of the users are using IPv6 to access Google services. By my calculation, if IPv6 continues to grow at that rate it will be sometime in the twenty-fifth century before all of the miracles of the Internet of Things are fully realized, just in time for Buck Rogers to use.

Based on the latest studies, the wireless sensor networking chip market increased by 300% in 2010 and is doubling yet again this year. More important for embedded systems developers, wireless-enabled sensor spending grew by 80% in 2010. This increased interest in embedded wireless connectivity is also reflected in the 2011 Embedded Market Study.   But with great opportunities come great challenges. In Ron Wilson's recent column on wireless networks he pointed to the serious problem of wireless security, especially as more of these networks use or interface to the wider Internet via the IPv6 protocol. In "Sensor Fusion brings situational awareness to health devices," Supreet Oberoi points out another serious problem: how do you collect, organize and respond to the information you are getting from the wireless sensors?   Elaborate, data-centric networking methods in the form of the Data Distribution Service and the Java Messaging protocol will go a long way toward solving the data management problem.   Then there is the problem of real time and deterministic performance over wireless sensor networks, given the fact that the IPv6 protocol many of these devices will connect to is still asynchronous, with no real global clocking mechanism. Specifications such as IEEE 1588 have emerged to deal with this but adoption is moving happening slowly. To fill in the gap, wireless network-specific protocols such as WirelessHART, 6LowWPAN, and AODV have been proposed.   Then there's the new IPv6 protocol which makes available unique URLs that are counted in the billions of billions of billions. Even if every human on the planet had his or her own URL address, the number of URLs still available is essentially infinite, raising the prospect that almost every embedded device in the world will have its own URL. Will sensors with 8- or 16bit MCUs be up to this challenge, or will 32bit MCUs dominate?   These are questions that I think need to be addressed and I look forward to hearing from you with your ideas and contributions.