idnits 2.17.1 draft-jiang-intarea-nmp-edge-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 14, 2022) is 741 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Working Group Z. Chen 3 Internet-Draft Huawei 4 Intended status: Experimental S. Jiang 5 Expires: October 16, 2022 April 14, 2022 7 Native Minimal Protocols with Flexibility at Edge Networks 8 draft-jiang-intarea-nmp-edge-01 10 Abstract 12 This document introduces a flexible native minimal protocol for fast 13 short packet transmission in edge networks, and can communicate with 14 IPv6 nodes through gateways. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 16, 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.1. Packet Header Format . . . . . . . . . . . . . . . . . . 4 55 4.1.1. Data Packet Header Format . . . . . . . . . . . . . . 5 56 4.1.2. Control Packet Format . . . . . . . . . . . . . . . . 6 57 4.2. Control Messages . . . . . . . . . . . . . . . . . . . . 6 58 4.2.1. Address Request and Assignment Messages . . . . . . . 6 59 4.2.2. Address Lease Extension Messages . . . . . . . . . . 7 60 4.3. DNS Delegation Messages . . . . . . . . . . . . . . . . . 8 61 4.4. Functionalities of Gateway . . . . . . . . . . . . . . . 9 62 4.4.1. Address Management . . . . . . . . . . . . . . . . . 9 63 4.4.2. Address Translation . . . . . . . . . . . . . . . . . 10 64 5. Renumber Considerations . . . . . . . . . . . . . . . . . . . 10 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 68 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 TCP/IP protocol suites are adopted widely in different areas. 74 However, there are still numerous edge networks uses non-IP 75 technologies like ZigBee, BLE, CAN-bus, and Modbus for different 76 reasons (e.g., power-constrained devices, low transport rate media). 77 For such networks, application-layer gateways (or protocol 78 tranlators) are usually deployed to connect them with the Internet, 79 as shown in Figure 1. 81 Data 82 +- - - - - - - - - - - - - - - - - - - + 83 | | 84 V V 85 +--+ ZigBee +--+ TCP/IP +--+ 86 | |<-------------->| |<--------------->| | 87 +--+ +--+ +--+ 88 Non-IP Gateway TCP/IP 89 Terminal Terminal 91 Figure 1: Communication Architecture with Application Gateway 93 The application-layer translation mechanism MAY bring three main 94 drawbacks: 1. End-to-end security channel like IPSec or TLS is not 95 supported, a malicious gateway may manipulate data that is transmited 96 between two terminals. 2. Non-IP terminals are invisible to the 97 TCP/IP network, which makes it hard to conduct QoS or OAM operations, 98 e.g., guaranteeing SLA of a specific non-IP terminal's traffic, or 99 "ping" a non-IP terminal. 3. When a non-IP terminal joins or one 100 leaves the network, corresponding rules SHOULD be configured on the 101 gateway, thus increasing operation costs (i.e., OPEX). 103 Therefore, it would be beneficial to make those non-IP terminals 104 adopt TCP/IP protocol suites, thus eliminating aforementioned 105 drawbacks. The Internet Protocol Version 6 (IPv6) is expected to 106 achieve the goal, however, it is challenging in some cases due to its 107 long address and header length (40 bytes in total). For instance, it 108 would consume more energy for power constrained terminals like IoT 109 devices, and would amplify flow completion time on low-rate transport 110 media or one with low MTU, thus decreasing user experiences. 112 To this end, this document proposes Native Minimal Protocol (NMP), 113 which is applied at edge networks by using minimal address length and 114 fields. Simultaneously, NMP eliminats the drawbacks that may brought 115 by application layer gateways. 117 2. Requirements Notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 3. Overview 127 NMP is an inter-node communication method and network layer protocol 128 for edge network with native addresses. It is designed for extreme 129 minimal IoT devices that communicates with each other and sometimes 130 with normal IP nodes. NMP nodes and NMP gateways use native short 131 addresses to identify themselves and use these addresses as source 132 and destination addresses for network communication. NMP data 133 packets and signaling packets are encapsulated in a simplified 134 manner. The NMP-IPv6 translation function is deployed on the gateway 135 to implement IP connections on the edge network. See Figure 2. 137 +-----------+ 138 +-----------+-IP network+-------------+ 139 | +-----------+ | 140 | +-----------------+---------+ | 141 | | IP Header | Payload | | 142 | +-----------------+---------+ | 143 | | 144 +----+-----+ +-----+----+ 145 | Gateway | | Gateway | 146 +----/+\---+ +----/+\---+ 147 / |+---------+---------+ / | \ 148 / || NMP hdr | Payload | / | \ 149 / |+---------+---------+ / | \ 150 / | \ +---------+---------+ | \ 151 / | \ | NMP hdr | Payload | | \ 152 / | \ +---------+---------+ | \ 153 O O O O O O 154 Terminals Terminals 156 NMP domain A: NMP domain B: 157 Address length= m Address length= n 159 Only Support Extreme Simplified Control Messages within NMP Domain 161 Figure 2: Overview of Native Minimal Protocol 163 4. Protocol Design 165 4.1. Packet Header Format 167 The first bit at the beginning of the packet header indicates whether 168 the packet is encapsulated with extreme concise format or not. If 169 the first bit is 0, packet format is specified as follows Figure 3. 171 +----------------+---------------------+---------------------+ 172 |Indicator(1 bit)| NMP Headers | Payload | 173 +----------------+---------------------+---------------------+ 175 Figure 3: Basic Format of Native Minimal Protocol Packet 177 o Indicator one-bit indicator to indicate whether extreme concise 178 format is used. 0 - NMP headers follows; 1 - undefined. 180 o NMP Headers Record the fileds of packet header in Section 4.1.1 . 182 o Payload The payload of the packet. For control plane packets, the 183 control plane messages defined in Section 4.1.2 are carried in 184 this part. 186 4.1.1. Data Packet Header Format 188 For data packet header, NMP uses bitmap with variable length to 189 indicate which in-line headers appear in the packet. The 190 specification is in Figure 4. 192 +----------------------+-------------------+ 193 | Bitmap | In-line Headers | 194 | (7 bits) | (variable length) | 195 +----------------------+-------------------+ 197 Figure 4: NMP Header Format 199 o Bitmap A variable-length bitmap with at least 7 bits is used to 200 indicate whether a NMP field is carried in a packet.The bit of 1 201 indicates that the packet carries this field and is located in the 202 following in-line headers field. The value 0 indicates that the 203 packet does not contain this field. The length of bitmap is 204 defined as follows. 206 +------------------+----------------------------+-----------------+ 207 | bitmap format |number of bits for indicator|scope fo headers | 208 +------------------+----------------------------+-----------------+ 209 | xxx xxx0 | 6 bits | header 1 ~ 6 | 210 +------------------+----------------------------+-----------------+ 212 o In-line Headers The headers in NMP packet. Each header 213 corresponds to a position in preceding bitmap. 215 +--------+----------------+---------------+ 216 | Bitpos | Header Name | Header Length | 217 +--------+----------------+---------------+ 218 | 1 | TTL | 8 bit | 219 +--------+----------------+---------------+ 220 | 2 | Total Length | 16 bit | 221 +--------+----------------+---------------+ 222 | 3 | Next Header | 8 bit | 223 +--------+----------------+---------------+ 224 | 4 | Reserved | N/A | 225 +--------+----------------+---------------+ 226 | 5 | Destination |Variable Length| 227 +--------+----------------+---------------+ 228 | 6 | Source |Variable Length| 229 +--------+----------------+---------------+ 230 | 7 |Next Bitmap Byte| N/A | 231 +--------+----------------+---------------+ 233 4.1.2. Control Packet Format 235 +----------------------+-------------------+ 236 | Message Type | Checksum | 237 | (8 bits) | (8 bits) | 238 +----------------------+-------------------+ 240 Figure 5: Control Packet Header Format 242 o Type This filed carries value to indicate the type of this control 243 message. 245 o Checksum The checksum is the 8-bit one's complement of the one's 246 complement sum of the entire control message, starting with the 247 message type field, and prepended with a "1" of indicator header 248 fields, as specified in Section 4.1. For computing the checksum, 249 the checksum field is first set to zero. 251 4.2. Control Messages 253 4.2.1. Address Request and Assignment Messages 255 A NMP host broadcasts an Address Request (AR) message to request an 256 address from the gateway of the NMP domain. The gateway sends an 257 Address Assignment (AA) message to the host to configure the host's 258 NMP address. #### Format of Address Request The value of the message 259 Type is 1. The message body is defined as follows. 261 +-------------------+-----------+ 262 | ID length (8 bits) | Host ID | 263 +-------------------+-----------+ 265 o ID length Length of this field is 1 octet. This header specifies 266 the length of the Host ID field, in octets. 268 o Host ID Indicates the identifier of the host that accesses the NMP 269 network. The identifier can be a MAC address or another globally 270 unique identifier. 272 4.2.1.1. Format of Address Assignment 274 The value of the message Type is 2. The message body is defined as 275 follows. 277 +-------------------+---------+---------+-----------+--------+ 278 |NMP Address Length | NMP | Gateway | ID length | Host ID| 279 | 8 bits | Address | Address | (8 bits) | | 280 +-------------------+---------+---------+-----------+--------+ 282 o NMP Address Length Length of this field is 1 octet. This 283 parameter specifies the length of the NMP address used in the 284 local NMP domain. 286 o NMP Address Network layer address assigned to the host node. The 287 length is specified by the NMP Address Length field. 289 o Gateway Address Network layer address of the gateway. The length 290 is the same as length of NMP Address 292 o ID length Length of this field is 1 octet. This header specifies 293 the length of the Host ID field, in octets. 295 o Host ID Indicates the identifier of the host that accesses the NMP 296 network. The identifier can be a MAC address or another globally 297 unique identifier. 299 4.2.2. Address Lease Extension Messages 301 To reduce the complexity of the NMP host, the gateway records the 302 lease information of each NMP address. When the lease of a host 303 address expires, the gateway sends a Renewal Challenge message to the 304 host and waits for an response from the host. If a Renewal Response 305 message is received from the host, the lease information is updated 306 based on the preconfigured strategy. Otherwise, the gateway releases 307 the NMP address. 309 4.2.2.1. Renewal Challenge Message 311 The value of the message Type is 3. The message body is defined as 312 follows. 314 +-------------------+---------+-----------+--------+ 315 |NMP Address Length | NMP | ID length | Host ID| 316 | 8 bits | Address | (8 bits) | | 317 +-------------------+---------+-----------+--------+ 319 o NMP Address Length Length of this field is 1 octet. This 320 parameter specifies the length of the NMP address used in the 321 local NMP domain. 323 o NMP Address Network layer address assigned to the host node. The 324 length is specified by the NMP Address Length field. 326 o ID length Length of this field is 1 octet. This header specifies 327 the length of the Host ID field, in octets. 329 o Host ID Indicates the identifier of the host that accesses the NMP 330 network. The identifier can be a MAC address or another globally 331 unique identifier. 333 4.2.2.2. Renewal Response Message 335 The value of the message Type is 4. The message body is defined in 336 Section 4.2.2.1. 338 4.3. DNS Delegation Messages 340 Many IoT products are written into the domain name of the IoT service 341 platform when they are manufactured. The IP address of the server 342 needs to be obtained through the DNS to establish communication. 344 Within the NMP domain, some modifications are required to traditional 345 DNS messages in [RFC1035]. The NMP host sends a DNS query packet to 346 the gateway. It Must set next header indicator to 1, the value of 347 in-line next header is 17. Destination port in UDP header is 53. 348 Destination of the packet is set to NMP address of gateway. When the 349 gateway receives the packet, it directly translates the network layer 350 information and sends a regular DNS packet to the DNS server 351 configured on the gateway. 353 NMP is replaced by IPv6 protocol after the gateway. The source 354 address is changed to 'IPv6 address prefix stored in the gateway + 355 padding bit + NMP address', the destination address is changed to the 356 DNS server address configured on the gateway, and the payload 357 information remains unchanged. 359 When the DNS response packet sent by the DNS server reaches the 360 gateway, the gateway resolves the response packet and allocates an 361 available NMP address to the destination IPv6 address. The NMP 362 address is used as an in-network mirror of the IPv6 address and 363 replaces the target address in the DNS response packet. Then, the 364 gateway sends the DNS response packet to the NMP host. 366 The header format of an DNS delegation message is defined as follows. 367 For details about the format of a DNS message body, see [RFC1035]. 369 +-+---------+---------+---------+---------+------------+-----------+ 370 |0| 0110110 | Total Length | Nxt Hdr | GW Addr | NMP src | 371 +-+---------+---------+---------+---------+------------+-----------+ 372 | UDP header(port=53) | | 373 +---------------------+ + 374 | | 375 | DNS message body defined in RFC 1035 | 376 | | 377 +------------------------------------------------------------------+ 379 4.4. Functionalities of Gateway 381 4.4.1. Address Management 383 The NMP gateway initializes the NMP address pool based on the network 384 configuration and assigns an address to itself. This address is used 385 as the default gateway by the hosts in the domain. 387 Intra-domain address management functionaliteis includes: * intra- 388 domain host address allocation The gateway listens to the NMP address 389 request message, allocates the corresponding NMP address based on the 390 message content, generates an address assignment message, and returns 391 the message to the host. The assigned addresses must meet the 392 uniqueness requirements within the NMP domain. * intra-domain host 393 address life cycle management The gateway manages the validity period 394 of NMP addresses. The lease renewal challenge mechanism is used to 395 renew or release host addresses. 397 4.4.2. Address Translation 399 The NMP address space can be mapped to specific subspaces of IPv6 400 address space. When traffic is destinated to a destination outside 401 the domain, the gateway translates the host address (source address) 402 in the domain into an IPv6 address. For details about the 403 translation method, see TBD. 405 For traffic from outside of the domain, determines whether the 406 destination is within the domain. If the destination is within the 407 domain, then the gateway translates the destination address to the 408 corresponding NMP address. 410 5. Renumber Considerations 412 The NMP renumbering problem is not beyond the scope of [RFC6866] and 413 [RFC7010], [RFC5887]. 415 6. Security Considerations 417 Checksum is used to defend against malformed packets and null packet 418 attacks caused by network bit errors. ICMPv6 uses a 16-bit checksum. 419 NMP uses an 8-bit checksum to reduce the computing load on the host 420 side and improve the packet encapsulation efficiency. This leads to 421 a higher probability of network errors. 423 7. IANA Considerations 425 If NMP is running on Ethernet, a new Ethtype is required. In 426 addition to Ethernet, other link-layer protocols that need to carry 427 multiple upper-layer protocols need to assign specific identifiers to 428 NMP to instruct devices to process network-layer packets according to 429 this document. 431 This document requires to define new registry for NMP control message 432 types, six of which are defined in this document. 434 8. Acknowledgments 436 The authors would like to acknowledge the contributions Guangpeng Li 437 and Zhaochen Shi provided during the development of the solution. 439 9. Normative References 441 [RFC1035] Mockapetris, P., "Domain names - implementation and 442 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 443 November 1987, . 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 451 Still Needs Work", RFC 5887, DOI 10.17487/RFC5887, May 452 2010, . 454 [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for 455 Renumbering IPv6 Hosts with Static Addresses in Enterprise 456 Networks", RFC 6866, DOI 10.17487/RFC6866, February 2013, 457 . 459 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 460 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 461 DOI 10.17487/RFC7010, September 2013, 462 . 464 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 465 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 466 May 2017, . 468 Authors' Addresses 470 Sheng Jiang 471 Huawei Technologies 472 Beiqing Road, Haidian District 473 Beijing 100095 474 P.R. China 476 Email: jiangsheng@huawei.com 478 Zhe Chen 479 Huawei Technologies 480 Beiqing Road, Haidian District 481 Beijing 100095 482 China 484 Email: chenzhe17@huawei.com