Mạng IoT có thể thúc đẩy việc áp dụng IPv6?

Chúng ta đang dần rời khỏi IPv4 và hướng tới IPv6, nhưng quá trình này có thể được tăng tốc vì việc áp dụng IPv6 có lợi thế cho việc kinh doanh bùng nổ của thị trường internet vạn vật IoT.

IPv6 có các đặc điểm để bổ sung cho những thiếu sót trong IPv4, tạo thuận lợi cho việc triển khai Internet of things IoT, như hỗ trợ các mạng IoT lớn, giúp duy trì tuổi thọ pin của các thiết bị IoT và giảm gánh nặng quản trị và bảo trì. Vậy thì, câu hỏi đặt ra là IoT có thể giúp thúc đẩy việc áp dụng IPv6 trong các mạng doanh nghiệp không?

 

IPv6 có nhiều địa chỉ hơn để sử dụng

Một vấn đề nhức nhối với IPv4 là nó chỉ hỗ trợ 4.2 tỷ địa chỉ có thể trong khi, theo một số ước tính, số lượng thiết bị kết nối internet dự kiến sẽ tăng lên 28,5 tỷ vào năm 2022. Đó là một sự thiếu hụt rất lớn có nghĩa là khi triển khai mạng IoT, hầu hết các thiết bị này không thể kết nối với internet mà không có lớp công nghệ can thiệp - dịch địa chỉ mạng (network address translation NAT) - cho phép một hoặc nhiều địa chỉ IP công cộng phục vụ nhiều địa chỉ IP riêng hoặc cục bộ.

IPv6, mặt khác, hỗ trợ khoảng 340 địa chỉ không chính xác hoặc 340 nghìn tỷ nghìn tỷ, đủ để cung cấp địa chỉ IP duy nhất trên toàn cầu cho mỗi thiết bị IoT. Và nó có thể làm như vậy mà không cần đầu tư thêm vào NAT.

 

IPv6 và Tuổi thọ của các thiết bị IoT

IPv4 cũng có những thiếu sót khi bảo toàn tuổi thọ pin các thiết bị IoT. Bởi vì nhiều thiết bị được kết nối chạy bằng pin và vì các mạng IoT, chẳng hạn như hệ thống cảm biến của nhà máy, có thể bao gồm hàng trăm hoặc hàng nghìn thiết bị, khiến pin tồn tại càng lâu càng tốt là một lợi thế rất lớn. Chỉ cần tưởng tượng chi phí về thời gian và công sức cần thiết để thay thế pin trong nhiều thiết bị IoT phân tán rộng rãi.

Với IPv4, nhắn tin quảng bá thường xuyên không cần thiết  (routine broadcast messaging unnecessarily) làm giảm tuổi thọ pin. Ví dụ, tin nhắn quảng bá được sử dụng cho các quy trình như Giao thức phân giải địa chỉ (ARP), được sử dụng để liên kết địa chỉ MAC với địa chỉ IPv4. Cách thức hoạt động, tin nhắn ARP được gửi đến mọi thiết bị trong mạng và mỗi thiết bị phải xử lý gói này và do đó sử dụng hết năng lượng pin, bất kể thiết bị đó có cần thiết để tham gia trao đổi hay không.

Sự không hiệu quả này cũng có thể phá vỡ toàn bộ mạng. Các vấn đề liên quan đến bão broadcast, khi các chương trình broadcasts được sử dụng thường xuyên trong một khoảng thời gian ngắn, đã được biết đến và loại sự kiện này sẽ gây bất lợi cho mạng IoT.

Với IPv6, không có chức năng broadcast. Thay vào đó, truyền thông đa hướng hiệu quả được sử dụng cho các giao tiếp một-nhiều (one-to-many) này. Thay vì phát broadcast, IPv6 Neighbor Discovery Protocol (NDP) sử dụng phát đa hướng hiệu quả với các địa chỉ phát đa hướng nút (node) để xây dựng và duy trì bộ đệm (neighbor cache). Gói Neighbor Solicitation (NS) được gửi đến chỉ một tập hợp con của tiền tố LAN Lát / 64 và gói Neighbor Advertisement packet được gửi lại bằng unicast.

Địa chỉ nhóm đa liên kết cục bộ liên kết IPv6 (FF02 :: 1) gần giống như IPv6 phát sóng và các thiết bị IoT cố gắng sử dụng tin nhắn unicast bất cứ khi nào có thể để tiết kiệm pin hơn nữa.

Cụ thể: Làm thế nào IPv6 có thể giảm tiêu thụ đối với pin của các thiết bị IoT
IPv6 cung cấp nhiều phương thức để tự động gán địa chỉ cho các thiết bị IoT. Các nút (node) IPv6 có nhiều địa chỉ, không giống như các nút IPv4 chỉ có một địa chỉ unicast duy nhất. Các nút IPv6 có địa chỉ liên kết cục bộ (FE80 :: / 10) và một hoặc nhiều địa chỉ unicast IPv6 trên mỗi giao diện. Địa chỉ liên kết cục bộ được sử dụng để khởi động và khởi động các địa chỉ unicast như một địa chỉ nguồn của thông báo Bộ định tuyến (RS) để khám phá bộ định tuyến cục bộ.

Bộ định tuyến bước đầu tiên gửi lại thông báo một Router Advertisement (RA) đến nhóm phát đa hướng tất cả các nút (FF02 :: 1) cho biết tiền tố IPv6 / 64 cục bộ và phương thức để lấy địa chỉ unicast của nó. Dựa trên các flag nhất định và các tùy chọn khác trong thông báo RA, một nút được yêu cầu sử dụng Tự động cấu hình địa chỉ không trạng thái (SLAAC) (RFC 4862), DHCPv6 (RFC 8415) hoặc Máy chủ DNS đệ quy (RDNSS) (RFC 8106). Nên sử dụng câu hỏi nào thường xuyên xuất hiện trong mạng doanh nghiệp.

Đối với các cảm biến thiếu sức mạnh tính toán mạnh mẽ cần thiết để chạy DHCPv6 và chỉ cần hoạt động trên mạng phẳng, SLAAC là một lựa chọn rõ ràng. Đối với máy tính để bàn và máy chủ của công ty, DHCPv6 đã được đề xuất, nhưng quyết định đã trở nên hơi u ám. Giờ đây, có nhiều HĐH hỗ trợ RDNSS, bao gồm cả Android, RDNSS đang trở thành một lựa chọn phổ biến.

Các gói RA thường được truyền bởi bộ định tuyến cục bộ cứ sau 200 giây để giữ cho tất cả các nút được thông báo về bất kỳ thay đổi nào. Các nút mới tham gia mạng không kiên nhẫn và gửi gói RS đến nhóm phát đa hướng liên kết cục bộ tất cả các bộ định tuyến (FF02 :: 2) để tìm hiểu về mạng mà chúng đã tham gia. Bộ định tuyến cục bộ ngay lập tức phản hồi RS bằng cách gửi RA tới tất cả các nút. Như bạn có thể tưởng tượng, điều này có thể tiêu thụ một số thời lượng pin có thể đo được trong một ứng dụng IoT và do đó, các tùy chọn để kiểm soát RA đã được tạo.

Một tùy chọn là sử dụng khoảng thời gian RA dài hơn cho mạng IoT. Các thiết bị IoT có thể chỉ cần nhận một tin nhắn RA một lần một ngày hoặc thậm chí lâu hơn. Tuy nhiên, bất cứ khi nào một thiết bị IoT mới tham gia vào mạng, nó sẽ gửi RA, kích hoạt một đa tuyến RA tất cả các nút được gửi bởi bộ định tuyến cục bộ.

Để tiếp tục hạn chế các gói đa tuyến Tất cả các nút, RA có thể được thay đổi thành gói tin unicast đến nút riêng lẻ gửi RS. Điều này sẽ ngăn bất kỳ nút được thiết lập nào khác nhận được multicast-RA. Tính năng này Unic Unicast-RA loại bỏ các RA được gửi đến nhóm đa tuyến Tất cả các nút. Điều này đã được triển khai trong các phiên bản Cisco IOS 15.4 (2) T, 15.4 (2) S, 15.2 (1) SY1 trở lên và được định cấu hình bằng cách sử dụng lệnh giao diện lớp 3.
 

Cải tiến giao thức IoT IPv6

IPv6 tạo điều kiện cho sự đổi mới và đã có sự phát triển đáng kể của các giao thức IoT có khả năng IPv6. Sau đây là một vài ví dụ về cách các mạng IoT có thể sử dụng IPv6.

IPv6 qua Mạng không dây cá nhân công suất thấp (6LoWPAN) cho phép các gói IPv6 được nén, đóng gói và chia thành nhiều khung nhỏ hơn được gửi qua mạng không dây IEEE 802.15.4 (RFC 4944 và RFC 6282). Do đó, 6LoWPAN yêu cầu thiết bị cổng (bộ định tuyến biên) để kết nối mạng IPv6 riêng với mạng thiết bị IoT. Mục tiêu là hạn chế hơn nữa việc sử dụng IPv6 multicast để tối đa hóa tuổi thọ pin (RFC 6775). Các phương thức này được sử dụng bởi bộ giao thức Zigbee.

IETF đang làm việc trên IPv6 qua các mạng WAN công suất thấp như LoRaWAN và Hướng dẫn thực hiện trọng lượng nhẹ (lwig) cho các thiết bị nhúng nhỏ sử dụng IPv6. IETF cũng đã tạo ra các giao thức định tuyến để sử dụng trên các Mạng tổn thất và năng lượng thấp (LLNs) này. IETF đã tạo ra Giao thức định tuyến IPv6 RPL: ​​IPv6 cho các mạng có công suất thấp và tổn thất mạng (RFC 6550) và giao thức đa tuyến cho các mạng có công suất thấp và tổn thất (MPL) (RFC 7731). RPL sử dụng IPv6 để khám phá tất cả các nút RPL bằng cách sử dụng nhóm đa hướng IPv6 FF02 :: 1A.

IETF đã phát triển các tiêu chuẩn về cách các thiết bị IoT giao tiếp qua IPv6 bằng giao diện web và RESTful (CoRE). Giao thức ứng dụng ràng buộc (CoAP) (RFC 7252) xác định phương thức cho các thiết bị IoT này sử dụng các dịch vụ web phổ biến. CoAP sử dụng nhóm đa hướng IPv6 FF0X :: FD (Tất cả các nút CoAP).

Giao thức Mobile IPv6 (MIPv6) (RFC 6275) đã được chỉ định trong nhiều năm như một cách để các thiết bị không bị ràng buộc duy trì liên lạc của chúng trong quá trình chuyển đổi giữa các mạng Lớp 3.

IPv6 thậm chí còn được sử dụng trong các mạng sản xuất IoT công nghiệp và robot. Giao thức thời gian chính xác (PTP) (IEEE 1588-2008) sử dụng đa tuyến IPv6 để đồng bộ hóa đồng hồ thành độ chính xác dưới micro giây cho vũ đạo chính xác của chuyển động tốc độ cao. PTP sử dụng các nhóm phát đa hướng IPv6 FF02 :: 6B và FF0X :: 181.

Khi các doanh nghiệp tiến hành triển khai bất kỳ loại ứng dụng IoT nào, họ nên tìm hiểu cách làm cho hệ thống đó sử dụng IPv6. Các kỹ sư mạng doanh nghiệp nên tích cực làm việc để triển khai cơ sở hạ tầng IPv6 trước mạng IoT đó trong khi bạn có thời gian. Họ sẽ triển khai một mạng IPv6 tốt hơn khi họ không vội vã bởi một dự án IoT chuyển động nhanh nhằm tiết kiệm tiền của tổ chức hoặc cung cấp một chức năng có giá trị. Một trong những bước đầu tiên cho các doanh nghiệp là lấy tài nguyên địa chỉ IPv6 của họ từ RIR, và sau đó làm theo hướng dẫn được ghi chép đầy đủ để triển khai IPv6.



English edition:
IPv6 has characteristics lacking in IPv4 that make it advantageous for internet of things deployments, such as supporting large IoT networks, helping preserve battery life of IoT devices and reducing administrative and maintenance burden.  Could IoT be helping to drive IPv6 adoption in enterprise networks?
 

IPv6 has plenty of addresses

One glaring problem with IPv4 is that it supports only 4.2 billion possible addresses while, by some estimates, the number of internet-connected devices is expected to grow to 28.5 billion by 2022. That’s an enormous shortfall that means when deploying IoT networks, most of these devices could not be connected to the internet without an intervening layer of technology – network address translation (NAT) – that lets one or more public IP addresses service many locally significant or private IP addresses.

IPv6, on the other hand, supports about 340 undecillion addresses or 340 trillion trillion trillion, which is enough to give universally unique IP addresses to each IoT device. And it could do so without requiring further investment in NAT.
 

IPv6 and IoT battery life

IPv4 also has shortcomings when it comes to preserving IoT battery life. Because many connected devices are battery-powered, and because IoT networks, such as factory sensor systems, can consist of hundreds or thousands of devices, making the batteries last as long as possible is a huge advantage. Just imagine the cost in time and effort required to replace batteries in many widely scattered IoT devices.

With IPv4, routine broadcast messaging unnecessarily saps battery life. For instance, broadcast messages are used for processes like Address Resolution Protocol (ARP) , which is used for binding MAC addresses to IPv4 addresses. The way it works, an ARP message is sent to every device in the network, and each device must process this packet, and therefore use up some battery power, regardless of whether it was necessary for that device to participate in the exchange. 

This inefficiency can also disrupt the network as a whole. The problems related to broadcast storms, when broadcasts are used frequently in a short period of time, are well known, and this type of event would be detrimental to an IoT network.

With IPv6, there is no broadcast function.  Instead, efficient multicast communications are used for these one-to-many communications.  Rather than broadcast, IPv6’s Neighbor Discovery Protocol (NDP) uses efficient multicast with solicited-node multicast addresses for building and maintaining a neighbor cache.  The Neighbor Solicitation (NS) packet is sent to only a minute subset of the LAN’s /64 prefix and the Neighbor Advertisement packet is sent back using unicast.

The IPv6 All-Nodes link-local multicasts group address (FF02::1) is as close as IPv6 comes to a broadcast, and IoT devices attempt to use unicast messages whenever possible to further conserve battery power.

Specifics: How IPv6 can reduce draws on IoT batteries
IPv6 offers a variety of methods for dynamically assigning addresses to IoT devices. IPv6 nodes have multiple addresses, unlike IPv4 nodes which only have a single unicast address. IPv6 nodes have a link-local address (FE80::/10) and one or more IPv6 unicast addresses per interface. The link-local address is used to “bootstrap” obtaining the unicast addresses as a source address of a Router Solicitation (RS) message to discover the local router.

The first-hop router sends back a Router Advertisement (RA) message to the all-nodes multicast group (FF02::1) indicating the local IPv6 /64 prefix and the method to obtain its unicast address.  Based on certain flags and other options in the RA message, a node is told to use either Stateless Address AutoConfiguration (SLAAC) (RFC 4862), Stateful DHCPv6 (RFC 8415) or Recursive DNS Server (RDNSS) (RFC 8106). Which to use is a question that comes up frequently in enterprise networks.

For sensors that lack the robust computing power needed to run DHCPv6 and only need to operate on a flat network, SLAAC is an obvious choice. For corporate desktops and servers, DHCPv6 has been the recommendation, but the decision has become a little murky.  Now that more OSs support RDNSS, including Android, RDNSS is becoming a popular choice.

RA packets are typically transmitted by the local router every 200 seconds to keep all the nodes informed of any changes.  New nodes that join the network are impatient and send a RS packet to the all-routers link-local multicast group (FF02::2) to learn about the network they have joined.  The local router immediately responds to the RS by sending an RA to all-nodes.  As you can imagine, this can consume some measurable battery life in an IoT application and, therefore, options to control RAs have been created.

One option is to use longer RA intervals for IoT networks.  IoT devices may only need to receive a single RA message once a day or even longer.  However, any time that a new IoT device joined the network, it would send an RA, triggering an all-nodes RA multicast to be sent by the local router.

To further restrict All-nodes multicast packets, the RA could be changed to be a unicast packet to the individual node that send the RS.  This would prevent any other established node from receiving the multicast-RA.  This “Unicast-RA” feature eliminates RAs sent to the All-nodes multicast group.  This has been implemented in Cisco IOS versions 15.4(2)T, 15.4(2)S, 15.2(1)SY1 and later and configured using the layer-3 interface command “ipv6 nd ra solicited unicast”.
 

Innovative IPv6 IoT Protocols

IPv6 facilitates innovation and there has been substantial development of IPv6-capable IoT protocols.  Following are a few examples of how IoT networks can use IPv6.

IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) allows IPv6 packets to be compressed, encapsulate and split up into multiple smaller frames to be sent over IEEE 802.15.4 wireless nets (RFC 4944 and RFC 6282).  Therefore, 6LoWPAN requires a gateway device (edge router) to connect the native IPv6 network to the IoT-device network. The goal is to further constrain the use of IPv6 multicast to maximize battery life (RFC 6775). These methods are used by the Zigbee suite of protocols.

The IETF is working on IPv6 over Low Power WANs like LoRaWAN and Light-Weight Implementation Guidance (lwig) for small embedded devices that use IPv6. The IETF has also created routing protocols for use on these Low power and Lossy Networks (LLNs) (roll).  The IETF has created “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks” (RFC 6550) and Multicast Protocol for Low-Power and Lossy Networks (MPL) (RFC 7731).  RPL uses IPv6 for discovery of all-RPL-nodes using the IPv6 multicast group FF02::1A.

The IETF has developed standards for how IoT devices communicate over IPv6 using web and RESTful interfaces (CoRE).  The Constrained Application Protocol(CoAP) (RFC 7252) defines the method for these IoT devices to use common web services.  CoAP uses the IPv6 multicast group FF0X::FD (All CoAP Nodes).

The Mobile IPv6 (MIPv6) protocol (RFC 6275) has been specified for many years as a way for unconstrained devices to maintain their communications during transition between Layer 3 networks.

IPv6 is even used in industrial IoT manufacturing and robotics networks.  The Precision Time Protocol (PTP) (IEEE 1588-2008) uses IPv6 multicast to synchronize clocks to sub-microsecond accuracy for precise choreography of high-speed movement.  PTP uses the IPv6 multicast groups FF02::6B and FF0X::181.

As enterprises proceed to deploy any type of IoT application, they should be exploring how to make that system utilize IPv6.  Enterprise network engineers should be actively working to deploy the IPv6 infrastructure in-advance of that IoT network while you have the time.  They will implement a better IPv6 network when they are not rushed by a rapidly-moving IoT project that saves the organization money or provides a valuable function.  One of the first steps for enterprises is to obtain their IPv6 address resources from the RIR, and then follow the well-documented guidance for IPv6 deployment.