1# New IP Kernel Protocol Stack 2 3 4## Basic Concepts 5 6On basis of the traditional IP, New IP employs lightweight packet headers and variable-length, multi-semantic addresses and integrates Layer 2 and Layer 3 protocols to simplify protocols, reduce redundant bytes, and improve the energy efficiency ratio (EER), net throughput, and communication efficiency. New IP strives to implement end-to-end interconnection between heterogeneous networks to support ultimate experience of Super Device via efficient communication between devices. 7 8The Wi-Fi protocol packets cause low transmission efficiency due to high overheads in Layer 3 packet headers and addressing. 9 10 11 12``` 13An IPv4 address has a fixed length of 4 bytes, and an IPv6 address has a fixed length of 16 bytes. 14The network layer header ranges from 20 to 60 bytes for an IPv4 packet and is 40 bytes for an IPv6 packet. 15``` 16 17New IP supports variable-length multi-semantic addresses (min. 1 byte) and customized header encapsulation (min. 5 bytes). Simplified packet headers reduce overheads and improve transmission efficiency. 18 19New IP provides 25.9% fewer packet header overheads than IPv4 and 44.9% less than IPv6. 20 21New IP provides at least 1% higher payload transmission efficiency than IPv4 and 2.33% higher than IPv6. 22 23| Scenario | Header Overhead (Bytes) | Payload Transmission Efficiency<br>(Wi-Fi MTU = 1500 Bytes, BT MTU = 255 Bytes)| 24| --------------- | ------------ | ------------------------------------------- | 25| IPv4 for Wi-Fi | 30 + 8 + 20 = 58 | (1500 - 58)/1500 = 96.13% | 26| IPv6 for Wi-Fi | 30 + 8 + 40 = 78 | (1500 - 78)/1500 = 94.8% | 27| New IP for Wi-Fi | 30 + 8 + 5 = 43 | (1500 - 43)/1500 = 97.13% | 28 29## Variable-Length Header Format 30 31The following figure shows a New IP Wi-Fi packet header. "EtherType = 0xEADD" in the LLC header identifies the New IP packet. A bitmap is a binary sequence. The value of each binary bit indicates whether a field is carried in the New IP header. That is, the New IP header can be customized based on service requirements. 32 33 34 35- **Dispatch** indicates the encapsulation type. The value **0b0** indicates the New IP encapsulation child class, which is 1 bit long (**0b** indicates that the following values are binary). 36 37- **Bitmap** is of variable length. By default, it is seven bits following the **Dispatch** valid bit. The length of **Bitmap** can be extended contiguously. If the last bit of **Bitmap** is **0**, it indicates the end of **Bitmap**. If the last bit is **1**, it means one more byte until the last bit **0**. 38- **Value** indicates the field value. The length is an integer multiple of 1 byte. The value type and length are determined by the semantic table of the header field. 39 40The **Bitmap** field is defined as follows: 41 42| Bitmap Identifier | Bitops | Length of the Field Carried (Byte) | Setting | Remarks | 43| ---------------------------- | ------ | ---------------- | -------------- | --------------------------------------- | 44| Bitmap first byte | - | - | - | The eight bits are from the most significant bit to the least significant bit. | 45| Dispatch | 0 | - | Set to **0**. | **0**: indicates a New IP packet; **1**: indicates a non-New-IP packet. | 46| Whether the packet header carries the TTL | 1 | 1 | Set to **1**. | Indicates the number of remaining hops. | 47| Whether the packet header carries the total length | 2 | 2 | Set to **0** for UDP and **1** for TCP.| Total length of the New IP packet (including the header) | 48| Whether the packet header carries the Next Header | 3 | 1 | Set to **1**. | Protocol type. | 49| Reserve | 4 | Reserved | Set to **0**. | Reserved. | 50| Whether the packet header carries the destination address | 5 | Variable length (1 to 8 bytes)| Set to **1**. | Destination address. | 51| Whether the packet header carries the source address| 6 | Variable length (1 to 8 bytes)| Determined by the protocol.| Source address. | 52| Flag bit, indicating whether there is the second byte | 7 | - | - | **0**: indicates the end of the bitmap. **1**: indicates another 8-bit bitmap.| 53| Bitmap second byte | - | - | - | The eight bits are from the most significant bit to the least significant bit. | 54| Whether the packet header carries the header Length | 0 | 1 | - | New IP header length. | 55| Reserve | 1 | Reserved | Set to **0**. | - | 56| Reserve | 2 | Reserved | Set to **0**. | - | 57| Reserve | 3 | Reserved | Set to **0**. | - | 58| Reserve | 4 | Reserved | Set to **0**. | - | 59| Reserve | 5 | Reserved | Set to **0**. | - | 60| Reserve | 6 | Reserved | Set to **0**. | - | 61| Flag bit, indicating whether there is the third byte | 7 | - | - | **0**: indicates the end of the bitmap. **1**: indicates another 8-bit bitmap.| 62 63The New IP header is parsed as follows: 64 65Only the bitmap fields defined in New IP are parsed. All the bitmap fields with unknown semantics are skipped. The start position of the packet is located for parsing based on the header length. If the packet header contains bitmap fields with unknown semantics and does not contain the header length, the packet will be discarded. 66 67## Variable-Length Address Format 68 69Different from IPv4 and IPv6, which use fixed-length addresses, New IP supports variable-length addresses and parse of the address length. The packet header may not carry the address length field. The encoding format of New IP addresses is as follows: 70 71| First Byte | Semantics | Valid Range of Address | 72| ---------- | ------------------------------------------------------------ | ------------------------------------------------------------ | 73| 0x00 | Address is 0 | [1 byte] 0 to 220 (0x00 to 0xDC) | 74| 0x01 | Address is 1 | - | 75| 0x02 | Address is 2 | - | 76| ... | ... | - | 77| 0xDC | Address is 220 | - | 78| 0xDD | An 16-bit address, which is 0 + 256 * (0xDD - 0xDD) + the last byte value | [2 bytes] 221 to 255 (0x**DD**DD to 0x**DD**FF) | 79| 0xDE | An 16-bit address, which is 0 + 256 * (0xDE - 0xDD) + the last byte value | [2 bytes] 256 to 511 (0x**DE**00 to 0x**DE**FF) | 80| 0xDF | An 16-bit address, which is 0 + 256 * (0xDF - 0xDD) + the last byte value | [2 bytes] 512 to 767 (0x**DF**00 to 0x**DF**FF) | 81| ... | ... | - | 82| 0xF0 | An 16-bit address, which is 0 + 256 * (0xF0 - 0xDD) + the last byte value | [2 bytes] 4864 to 5119 (0x**F0**00 to 0x**F0**FF) | 83| 0xF1 | An 16-bit address is followed | [3 bytes] 5120 to 65535 (0x**F1** 1400 to 0x**F1** FFFF) | 84| 0xF2 | An 32-bit address is followed | [5 bytes] 65536 to 4,294,967,295 (0x**F2** 0001 0000 to 0x**F2** FFFF FFFF)| 85| 0xF3 | An 48-bit address is followed | [7 bytes] 4,294,967,296 to 281,474,976,710,655 (0x**F3** 0001 0000 0000 to 0x**F3** FFFF FFFF FFFF)| 86| 0xFE | An 56-bit address is followed | [8 bytes] 0 to 72,057,594,037,927,935 (0x**FE**00 0000 0000 0000 to 0x**FE**FF FFFF FFFF FFFF)| 87 88 89 90## New IP Configuration 91 92### Enabling New IP 93 94Only the Linux 5.10 kernel of the RK3568 development board supports the New IP kernel protocol stack. To enable New IP, search for "NEWIP" in the kernel module configuration file of the RK3568 development board and set related parameters as follows: 95 96``` 97# kernel/linux/config/linux-5.10/arch/arm64/configs/rk3568_standard_defconfig 98CONFIG_NEWIP=y // Enable the New IP kernel protocol stack. 99CONFIG_NEWIP_HOOKS=y // Enable New IP stub functions to be dynamically registered non-disruptively. This feature must be enabled when New IP is enabled. 100HCK_VENDOR_HOOKS=y // Enable the basic kernel instrumentation framework. New IP depends on this framework. It is enabled by default on the RK3568 development board. 101``` 102 103Run the following command to check whether the New IP protocol stack is successfully enabled: 104 105``` 106find out/ -name *nip*.o 107... 108out/kernel/OBJ/linux-5.10/net/newip/nip_addrconf_core.o 109out/kernel/OBJ/linux-5.10/net/newip/nip_hdr_decap.o 110out/kernel/OBJ/linux-5.10/net/newip/nip_addr.o 111out/kernel/OBJ/linux-5.10/net/newip/nip_checksum.o 112out/kernel/OBJ/linux-5.10/net/newip/tcp_nip_output.o 113... 114``` 115 116> **NOTE** 117> 118> All native kernel code must be non-disruptively modified into stub functions. For example, when New IP is added to the common process of IPv4/IPv6 stacks, you need to break into New IP stubs instead of calling New IP functions directly. After New IP is enabled, register the New IP functions with the function pointers during module initialization. Then, the New IP functions can be called in the common IPv4/IPv6 process through the function pointers. 119 120```c 121/* Register the New IP ehash function with the kernel. */ 122/* Call the newip hook function in sk_ehashfn function (net\ipv4\inet_hashtables.c): 123 */ 124void nip_ninet_ehashfn(const struct sock *sk, u32 *ret) 125{ 126 *ret = ninet_ehashfn(sock_net(sk), &sk->SK_NIP_RCV_SADDR, 127 sk->sk_num, &sk->SK_NIP_DADDR, sk->sk_dport); 128} 129 130void nip_ninet_ehashfn_lhck_register(void) 131{ 132 REGISTER_HCK_LITE_HOOK(nip_ninet_ehashfn_lhck, nip_ninet_ehashfn); 133} 134 135/* Add the New IP stack processing to the general entry function of IPv4/IPv6 stacks. */ 136static u32 sk_ehashfn(const struct sock *sk) 137{ 138 /* IPv6 */ 139#if IS_ENABLED(CONFIG_IPV6) 140 if (sk->sk_family == AF_INET6 && 141 !ipv6_addr_v4mapped(&sk->sk_v6_daddr)) 142 return inet6_ehashfn(sock_net(sk), 143 &sk->sk_v6_rcv_saddr, sk->sk_num, 144 &sk->sk_v6_daddr, sk->sk_dport); 145#endif 146 147 if (sk->sk_family == AF_NINET) { 148 u32 ret = 0; 149 150 /* Register the New IP ehash function. */ 151 CALL_HCK_LITE_HOOK(nip_ninet_ehashfn_lhck, sk, &ret); 152 return ret; 153 } 154 /* IPv4 */ 155 return inet_ehashfn(sock_net(sk), 156 sk->sk_rcv_saddr, sk->sk_num, 157 sk->sk_daddr, sk->sk_dport); 158} 159``` 160 161### Disabling New IP 162 163To disable New IP, search for "NEWIP" in the kernel module configuration file of the RK3568 development board and delete or comment out "CONFIG_NEWIP=y" and "CONFIG_NEWIP_HOOKS=y". 164 165``` 166# kernel/linux/config/linux-5.10/arch/arm64/configs/rk3568_standard_defconfig 167# CONFIG_NEWIP is not set 168# CONFIG_NEWIP_HOOKS is not set 169``` 170 171## New IP APIs 172 173The user-mode application calls **socket()** to create a New IP socket and uses the New IP frame header encapsulation to send and receive packets. The following table lists the socket APIs for New IP. 174 175| API | Input | Output | Return Value | Description | 176| -------- | ------------------------------------------------------------ | ---------------------------------------------- | ---------------- | ------------------------------------------------------------ | 177| socket | int **domain**, int type, int **protocol** | NA | Socket handle **sockfd**.| Creates a New IP socket. <br>**domain** must be **AF_NINET**, which indicates a New IP socket.<br>**protocol** can be **IPPROTO_TCP** or **IPPROTO_UDP**.<br>This API returns the handle of the **socket** instance created. | 178| bind | int sockfd, const **struct sockaddr_nin** *myaddr, socklen_t addrlen | NA | Error code, which is an integer. | Binds the **socket** instance to the specified IP address and port.<br>**myaddr->sin_family** must be **AF_NINET**. | 179| listen | int socket, int backlog | NA | Error code, which is an integer. | Listens for the New IP address and port from the server. | 180| connect | int sockfd, const **struct sockaddr_nin** *addr, aocklen_t addrlen | NA | Error code, which is an integer. | Sets up a connection between the client and the server. | 181| accept | int sockfd, **struct sockaddr_nin** *address, socklen_t *address_len | NA | **sockfd**. | Accepts the connection request from the client. | 182| send | int sockfd, const void *msg, int len, unsigned int flags, const **struct sockaddr_nin** *dst_addr, int addrlen | NA | Error code, which is an integer. | Sends New IP packets via the socket using TCP. | 183| recv | int sockfd, size_t len, int flags, **struct sockaddr_nin** *src_addr, | void **buf, int* *fromlen | Error code, which is an integer. | Receives New IP packets via the socket using TCP. | 184| close | int sockfd | NA | Error code, which is an integer. | Closes the socket to release resources. | 185| ioctl | int sockfd, unsigned long cmd, ... | NA | Error code, which is an integer. | Queries or modifies information about the New IP protocol stack. | 186| sendto | int sockfd, const void *msg, int len, unsigned int flags, const **struct sockaddr** *dst_addr, int addrlen | NA | Error code, which is an integer. | Sends New IP packets via the socket using UDP. | 187| recvfrom | int sockfd, size_t len, int flags, | void *buf, struct sockaddr *from, int *fromlen | Error code, which is an integer. | Receives New IP packets via the socket using UDP. | 188 189The structure of the New IP short address is as follows: 190 191```c 192enum nip_8bit_addr_index { 193 NIP_8BIT_ADDR_INDEX_0 = 0, 194 NIP_8BIT_ADDR_INDEX_1 = 1, 195 NIP_8BIT_ADDR_INDEX_2 = 2, 196 NIP_8BIT_ADDR_INDEX_3 = 3, 197 NIP_8BIT_ADDR_INDEX_4 = 4, 198 NIP_8BIT_ADDR_INDEX_5 = 5, 199 NIP_8BIT_ADDR_INDEX_6 = 6, 200 NIP_8BIT_ADDR_INDEX_7 = 7, 201 NIP_8BIT_ADDR_INDEX_MAX, 202}; 203 204enum nip_16bit_addr_index { 205 NIP_16BIT_ADDR_INDEX_0 = 0, 206 NIP_16BIT_ADDR_INDEX_1 = 1, 207 NIP_16BIT_ADDR_INDEX_2 = 2, 208 NIP_16BIT_ADDR_INDEX_3 = 3, 209 NIP_16BIT_ADDR_INDEX_MAX, 210}; 211 212enum nip_32bit_addr_index { 213 NIP_32BIT_ADDR_INDEX_0 = 0, 214 NIP_32BIT_ADDR_INDEX_1 = 1, 215 NIP_32BIT_ADDR_INDEX_MAX, 216}; 217 218#define nip_addr_field8 v.u.field8 219#define nip_addr_field16 v.u.field16 220#define nip_addr_field32 v.u.field32 221 222#pragma pack(1) 223struct nip_addr_field { 224 union { 225 unsigned char field8[NIP_8BIT_ADDR_INDEX_MAX]; 226 unsigned short field16[NIP_16BIT_ADDR_INDEX_MAX]; /* Big-endian */ 227 unsigned int field32[NIP_32BIT_ADDR_INDEX_MAX]; /* Big-endian */ 228 } u; 229}; 230 231struct nip_addr { 232 unsigned char bitlen; /* The address length is in bit (not byte). */ 233 struct nip_addr_field v; 234}; 235#pragma pack() 236 237/* The following structure must be larger than V4. System calls use V4. 238 * If the definition is smaller than V4, the read process will have memory overruns 239 * v4: include\linux\socket.h --> sockaddr (16Byte) 240 */ 241#define POD_SOCKADDR_SIZE 3 242struct sockaddr_nin { 243 unsigned short sin_family; /* [2 bytes] AF_NINET */ 244 unsigned short sin_port; /* [2 bytes] Transport layer port, big-endian */ 245 struct nip_addr sin_addr; /* [9 bytes] New IP address */ 246 247 unsigned char sin_zero[POD_SOCKADDR_SIZE]; /* [3 bytes] Byte alignment */ 248}; 249``` 250 251## New IP Development 252 253Only the OpenHarmony Linux-5.10 kernel supports New IP kernel protocol stack. You must manually configure IP address and route data for New IP in user mode, and connect the two devices through the router Wi-Fi. If you want to automatically switch to the New IP kernel protocol stack after configuring the New IP address and route, see the description in the blue box in the following figure. 254 255 256 257For details about the address and route configuration, see [examples](https://gitee.com/openharmony/kernel_linux_common_modules/tree/master/newip/examples). Modify the CC definition in Makefile based on the CPU you use, compile the CC definition into a binary file, and push the file to the development board. Refer to the figure above to configure the address and route data for New IP. 258 259| File | Description | 260| ------------------ | -------------------------------------------------------- | 261| nip_addr.c | Sample code for configuring variable-length New IP addresses (any valid New IP address can be configured).| 262| nip_route.c | Sample code for configuring New IP route information (any valid New IP address can be configured). | 263| check_nip_enable.c | Code for obtaining the New IP capabilities of the local host. | 264 265Check the New IP address and route information on device 1. 266 267```sh 268# cat /proc/net/nip_addr 26901 wlan0 270# cat /proc/net/nip_route 27102 ff09 1 wlan0 # Route to device 2. 27201 01 2149580801 wlan0 # Route for sending packets to itself and receiving the packets. 273``` 274 275Check the New IP address and route information on device 2. 276 277```sh 278# cat /proc/net/nip_addr 27902 wlan0 280# cat /proc/net/nip_route 28101 ff09 1 wlan0 # Route to device 1. 28202 02 2149580801 wlan0 # Route for sending packets to itself and receiving the packets. 283``` 284 285## Sample Code for Receiving and Sending New IP Packets 286 287The following table lists the related sample code. For details about how to use the user-mode APIs of the New IP stack, see [examples](https://gitee.com/openharmony/kernel_linux_common_modules/tree/master/newip/examples). Fixed addresses and routes are configured in the demo code. You do not need to manually specify the addresses and routes when executing the binary program. 288 289| File | Description | 290| --------------------- | ------------------------------ | 291| nip_addr_cfg_demo.c | Sample code for configuring variable-length IP addresses. | 292| nip_route_cfg_demo.c | Sample code for configuring NEW IP routes. | 293| nip_udp_server_demo.c | Sample code for the server to send and receive New IP packets using UDP.| 294| nip_udp_client_demo.c | Sample code for the client to send and receive New IP packets using UDP.| 295| nip_tcp_server_demo.c | Sample code for the server to send and receive New IP packets using TCP.| 296| nip_tcp_client_demo.c | Sample code for the client to send and receive New IP packets using TCP.| 297| nip_lib.c | API demo code, for example, obtaining the interface index. | 298 299**Basic Procedure** 300 301 302 3031. Copy the demo code to the Linux compiler, and run **make clean** and **make all** to compile the demo code. 304 3052. Upload the generated binary files to device 1 and device 2. 306 3073. Run the **ifconfig wlan0 up** command to start the network adapter. 308 3094. Run the **./nip_addr_cfg_demo server** command on shell of device 1 to configure a variable-length address **0xDE00** (2 bytes) for the server. Run the **./nip_addr_cfg_demo client** command on shell of device 2 to configure a variable-length address **0x50** (1 byte) for the client. Run **cat /proc/net/nip_addr** to view the configuration result. 310 3115. Run the **./nip_route_cfg_demo server** command on shell of device 1 to configure the server route data. Run the **./nip_route_cfg_demo client** command on shell of device 2 to configure the client route data. Then, run the **cat /proc/net/nip_route** command to check the kernel route configuration. 312 313Now, you can send and receive packets over UDP/TCP. By default, the addresses and routes configured are used for sending and receiving packets. 314 315 316 317**Sending and Receiving Packets over UDP** 318 319Run the **./nip_udp_server_demo** command on the server and then the **./nip_udp_client_demo** command on the client. The client sends 10 New IP packets. After receiving the packets, the server sends them to the client. 320 321``` 322The following information is displayed in the shell window on the server: 323Received -- 1661826989 498038 NIP_UDP # 0 -- from 0x50:57605 324Sending -- 1661826989 498038 NIP_UDP # 0 -- to 0x50:57605 325Received -- 1661826990 14641 NIP_UDP # 1 -- from 0x50:57605 326Sending -- 1661826990 14641 NIP_UDP # 1 -- to 0x50:57605 327Received -- 1661826990 518388 NIP_UDP # 2 -- from 0x50:57605 328Sending -- 1661826990 518388 NIP_UDP # 2 -- to 0x50:57605 329... 330Received -- 1661827011 590576 NIP_UDP # 9 -- from 0x50:37758 331Sending -- 1661827011 590576 NIP_UDP # 9 -- to 0x50:37758 332 333The following information is displayed in the shell window on the client: 334Received --1661827007 55221 NIP_UDP # 0 sock 3 success: 1/ 1/no= 0 335Received --1661827007 557926 NIP_UDP # 1 sock 3 success: 2/ 2/no= 1 336Received --1661827008 62653 NIP_UDP # 2 sock 3 success: 3/ 3/no= 2 337... 338Received --1661827011 590576 NIP_UDP # 9 sock 3 success: 10/ 10/no= 9 339``` 340 341 342 343**Sending and Receiving Packets over TCP** 344 345Run the **./nip_tcp_server_demo** command on the server and then the **./nip_tcp_client_demo** command on the client. The client sends 10 New IP packets. After receiving the packets, the server sends them to the client. 346 347``` 348The following information is displayed in the shell window on the server: 349Received -- 1661760202 560605 NIP_TCP # 0 --:1024 350Sending -- 1661760202 560605 NIP_TCP # 0 --:1024 351Received -- 1661760203 69254 NIP_TCP # 1 --:1024 352Sending -- 1661760203 69254 NIP_TCP # 1 --:1024 353Received -- 1661760203 571604 NIP_TCP # 2 --:1024 354Sending -- 1661760203 571604 NIP_TCP # 2 --:1024 355... 356Received -- 1661760207 86544 NIP_TCP # 9 --:1024 357Sending -- 1661760207 86544 NIP_TCP # 9 --:1024 358 359The following information is displayed in the shell window on the client: 360Received --1661760202 560605 NIP_TCP # 0 sock 3 success: 1/ 1/no= 0 361Received --1661760203 69254 NIP_TCP # 1 sock 3 success: 2/ 2/no= 1 362... 363Received --1661760207 86544 NIP_TCP # 9 sock 3 success: 10/ 10/no= 9 364``` 365 366## SELinux Policy 367 368The SELinux policy must be added for the user-mode process to use New IP sockets. Otherwise, the operation will be intercepted. 369 370```sh 371# base\security\selinux\sepolicy\ohos_policy\xxx\xxx.te 372# socket operation 373# avc: denied { create } for pid=540 comm="thread_xxx" scontext=u:r:thread_xxx:s0 tcontext=u:r:thread_xxx:s0 tclass=socket permissive=0 374allow thread_xxx thread_xxx:socket { create bind connect listen accept read write shutdown setopt getopt }; 375 376# ioctl operation 377# The operation code is defined in linux-xxx\include\uapi\linux\sockios.h. 378# 0x8933 : name -> if_index mapping 379# 0x8916 : set PA address 380# 0x890B : add routing table entry 381allowxperm thread_xxx thread_xxx:socket ioctl { 0x8933 0x8916 0x890B }; 382``` 383 384## WireShark Packet Parsing Template 385 386The default packet parsing rules of Wireshark cannot parse New IP packets. You can add a New IP packet parsing template to Wireshark to parse New IP packets. For details about the template, see [New IP packet parsing template](https://gitee.com/openharmony/kernel_linux_common_modules/blob/master/newip/tools/wireshark_cfg_for_newip.lua). 387 388The procedure is as follows: 389 3901. Choose **Help** > **About Wireshark** > **Folders**, and open the **init.lua** file in the **Global Configuration** directory. 3912. Add **dofile (DATA_DIR.."newip.lua")** to the end of the file. *DATA_DIR* is the path of the **newip.lua** file. 392 393 394 395Example: 396 397``` 398Path of the New IP packet parsing template: 399D:\tools\WireShark\wireshark_cfg_for_newip.lua 400 401Path of the WireShark configuration file: 402C:\Program Files\Wireshark\init.lua 403 404Add the following to the end of the init.lua file (Windows 11, for example): 405dofile("D:\\tools\\WireShark\\wireshark_cfg_for_newip.lua") 406``` 407 408### Packet Parsing Example 409 410#### ND Request 411 412The following figure shows the format of a New IP Neighbor Discovery (ND) request packet. The header contains a 1-byte bitmap (**0x76**), which is followed by the TTL, total length of the packet, upper-layer protocol type, destination address, and source address. The New IP ND request packet contains the packet type, operation code, checksum, and request address. 413 414> **NOTE** 415> 416> New IP supports variable-length addresses (1 to 8 bytes). The 1-byte address in Bitmap 1 indicates that the address carried in the current packet header is of 1 byte. 417 418 419 420 421 422#### ND Response 423 424The following figure shows the format of a New IP ND response packet. The New IP header contains two bitmaps (**0x77** and **0x00**). Bitmap1 is followed by the TTL, total packet length, upper-layer protocol type, destination address, and source address. Bitmap2 is used for byte alignment and does not carry any data. (For the rk3568 development board, the data transmitted in the link layer must be of an even number of bytes.) A New IP ND response packet contains the packet type, operation code, checksum, neighbor MAC address length, and neighbor MAC address. 425 426> **NOTE** 427> 428> New IP supports variable-length addresses (1 to 8 bytes). The 1-byte address in Bitmap 1 indicates that the address carried in the current packet header is of 1 byte. 429 430 431 432 433 434#### TCP Handshake 435 436The figure below shows the format of a TCP three-way handshake SYN packet. The New IP packet header contains two bitmaps (**0x77** and **0x00**). Bitmap1 is followed by the TTL, total packet length, upper-layer protocol type, destination address, and source address. Bitmap2 is used for byte alignment and does not carry any data. (For the rk3568 development board, the data transmitted in the link layer must be of an even number of bytes.) 437 438> **NOTE** 439> 440> New IP supports variable-length addresses (1 to 8 bytes). The 1-byte address in Bitmap 1 indicates that the address carried in the current packet header is of 1 byte. 441 442 443 444 445 446#### TCP Data Packet 447 448The figure below shows the TCP data format. The New IP header contains two bitmaps (**0x77** and **0x00**). Bitmap 1 is followed by the TTL, total packet length, upper-layer protocol type, destination address, and source address. Bitmap2 is used for byte alignment and does not carry any data. (For the rk3568 development board, the data transmitted in the link layer must be of an even number of bytes.) 449 450> **NOTE** 451> 452> New IP supports variable-length addresses (1 to 8 bytes). The 1-byte address in Bitmap 1 indicates that the address carried in the current packet header is of 1 byte. 453 454 455 456 457
