tag 标签: ipv6

相关帖子
相关博文
  • 热度 7
    2022-10-13 16:57
    1099 次阅读|
    0 个评论
    尽管从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地址所需的步骤,希望能帮助到大家!
  • 热度 9
    2022-9-8 16:26
    1137 次阅读|
    0 个评论
    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,空间更大,可以更好的满足需求。
  • 热度 24
    2015-1-22 19:16
    2908 次阅读|
    3 个评论
    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.
  • 热度 17
    2011-6-14 11:41
    2381 次阅读|
    1 个评论
    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.    
相关资源