| < draft-jiang-intarea-nmp-edge-00.txt | draft-jiang-intarea-nmp-edge-01.txt > | |||
|---|---|---|---|---|
| Internet Area Working Group S. Jiang | Internet Area Working Group Z. Chen | |||
| Internet-Draft Huawei | Internet-Draft Huawei | |||
| Intended status: Experimental 25 October 2021 | Intended status: Experimental S. Jiang | |||
| Expires: 28 April 2022 | Expires: October 16, 2022 April 14, 2022 | |||
| Native Minimal Protocols with Flexibility at Edge Networks | Native Minimal Protocols with Flexibility at Edge Networks | |||
| draft-jiang-intarea-nmp-edge-00 | draft-jiang-intarea-nmp-edge-01 | |||
| Abstract | Abstract | |||
| This document introduces a flexible native minimal protocol for fast | This document introduces a flexible native minimal protocol for fast | |||
| short packet transmission in edge networks, and can communicate with | short packet transmission in edge networks, and can communicate with | |||
| IPv6 nodes through gateways. | IPv6 nodes through gateways. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 1, line 32 ¶ | skipping to change at page 1, line 32 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 28 April 2022. | This Internet-Draft will expire on October 16, 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
| license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
| and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
| extracted from this document must include Simplified BSD License text | to this document. Code Components extracted from this document must | |||
| as described in Section 4.e of the Trust Legal Provisions and are | include Simplified BSD License text as described in Section 4.e of | |||
| provided without warranty as described in the Simplified BSD License. | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 | 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4.1. Packet Header Format . . . . . . . . . . . . . . . . . . 4 | 4.1. Packet Header Format . . . . . . . . . . . . . . . . . . 4 | |||
| 4.1.1. Data Packet Header Format . . . . . . . . . . . . . . 5 | 4.1.1. Data Packet Header Format . . . . . . . . . . . . . . 5 | |||
| 4.1.2. Control Packet Header Format . . . . . . . . . . . . 6 | 4.1.2. Control Packet Format . . . . . . . . . . . . . . . . 6 | |||
| 4.2. Control Messages . . . . . . . . . . . . . . . . . . . . 6 | 4.2. Control Messages . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.2.1. Address Request and Assignment Messages . . . . . . . 6 | 4.2.1. Address Request and Assignment Messages . . . . . . . 6 | |||
| 4.2.2. Address Lease Extension Messages . . . . . . . . . . 7 | 4.2.2. Address Lease Extension Messages . . . . . . . . . . 7 | |||
| 4.3. DNS Delegation Messages . . . . . . . . . . . . . . . . . 8 | 4.3. DNS Delegation Messages . . . . . . . . . . . . . . . . . 8 | |||
| 4.4. Functionalities of Gateway . . . . . . . . . . . . . . . 9 | 4.4. Functionalities of Gateway . . . . . . . . . . . . . . . 9 | |||
| 4.4.1. Address Management . . . . . . . . . . . . . . . . . 9 | 4.4.1. Address Management . . . . . . . . . . . . . . . . . 9 | |||
| 4.4.2. Address Translation . . . . . . . . . . . . . . . . . 9 | 4.4.2. Address Translation . . . . . . . . . . . . . . . . . 10 | |||
| 5. Renumber Considerations . . . . . . . . . . . . . . . . . . . 10 | 5. Renumber Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 | 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
| 1. Introduction | 1. Introduction | |||
| TCP/IP protocol suites are adopted widely in different areas. | TCP/IP protocol suites are adopted widely in different areas. | |||
| However, there are still numerous edge networks uses non-IP | However, there are still numerous edge networks uses non-IP | |||
| technologies like ZigBee, BLE, CAN-bus, and Modbus for different | technologies like ZigBee, BLE, CAN-bus, and Modbus for different | |||
| reasons (e.g., power-constrained devices, low transport rate media). | reasons (e.g., power-constrained devices, low transport rate media). | |||
| For such networks, application-layer gateways (or protocol | For such networks, application-layer gateways (or protocol | |||
| tranlators) are usually deployed to connect them with the Internet, | tranlators) are usually deployed to connect them with the Internet, | |||
| as shown in Figure 1. | as shown in Figure 1. | |||
| skipping to change at page 2, line 52 ¶ | skipping to change at page 3, line 5 ¶ | |||
| | |<-------------->| |<--------------->| | | | |<-------------->| |<--------------->| | | |||
| +--+ +--+ +--+ | +--+ +--+ +--+ | |||
| Non-IP Gateway TCP/IP | Non-IP Gateway TCP/IP | |||
| Terminal Terminal | Terminal Terminal | |||
| Figure 1: Communication Architecture with Application Gateway | Figure 1: Communication Architecture with Application Gateway | |||
| The application-layer translation mechanism MAY bring three main | The application-layer translation mechanism MAY bring three main | |||
| drawbacks: 1. End-to-end security channel like IPSec or TLS is not | drawbacks: 1. End-to-end security channel like IPSec or TLS is not | |||
| supported, a malicious gateway may manipulate data that is transmited | supported, a malicious gateway may manipulate data that is transmited | |||
| between two terminals. 2. Non-IP terminals are invisible to the TCP/ | between two terminals. 2. Non-IP terminals are invisible to the | |||
| IP network, which makes it hard to conduct QoS or OAM operations, | TCP/IP network, which makes it hard to conduct QoS or OAM operations, | |||
| e.g., guaranteeing SLA of a specific non-IP terminal's traffic, or | e.g., guaranteeing SLA of a specific non-IP terminal's traffic, or | |||
| "ping" a non-IP terminal. 3. When a non-IP terminal joins or one | "ping" a non-IP terminal. 3. When a non-IP terminal joins or one | |||
| leaves the network, corresponding rules SHOULD be configured on the | leaves the network, corresponding rules SHOULD be configured on the | |||
| gateway, thus increasing operation costs (i.e., OPEX). | gateway, thus increasing operation costs (i.e., OPEX). | |||
| Therefore, it would be beneficial to make those non-IP terminals | Therefore, it would be beneficial to make those non-IP terminals | |||
| adopt TCP/IP protocol suites, thus eliminating aforementioned | adopt TCP/IP protocol suites, thus eliminating aforementioned | |||
| drawbacks. The Internet Protocol Version 6 (IPv6) is expected to | drawbacks. The Internet Protocol Version 6 (IPv6) is expected to | |||
| achieve the goal, however, it is challenging in some cases due to its | achieve the goal, however, it is challenging in some cases due to its | |||
| long address and header length (40 bytes in total). For instance, it | long address and header length (40 bytes in total). For instance, it | |||
| would consume more energy for power constrained terminals like IoT | would consume more energy for power constrained terminals like IoT | |||
| devices, and would amplify flow completion time on low-rate transport | devices, and would amplify flow completion time on low-rate transport | |||
| skipping to change at page 4, line 36 ¶ | skipping to change at page 4, line 36 ¶ | |||
| Only Support Extreme Simplified Control Messages within NMP Domain | Only Support Extreme Simplified Control Messages within NMP Domain | |||
| Figure 2: Overview of Native Minimal Protocol | Figure 2: Overview of Native Minimal Protocol | |||
| 4. Protocol Design | 4. Protocol Design | |||
| 4.1. Packet Header Format | 4.1. Packet Header Format | |||
| The first bit at the beginning of the packet header indicates whether | The first bit at the beginning of the packet header indicates whether | |||
| the packet is a control message or a data packet. The basic format | the packet is encapsulated with extreme concise format or not. If | |||
| is specified as follows Figure 3. | the first bit is 0, packet format is specified as follows Figure 3. | |||
| +----------------+---------------------+---------------------+ | +----------------+---------------------+---------------------+ | |||
| |Indicator(1 bit)|Data/Control Headers | Payload/MessageBody | | |Indicator(1 bit)| NMP Headers | Payload | | |||
| +----------------+---------------------+---------------------+ | +----------------+---------------------+---------------------+ | |||
| Figure 3: Basic Format of Native Minimal Protocol Packet | Figure 3: Basic Format of Native Minimal Protocol Packet | |||
| * Indicator one-bit indicator to indicate Data or Control packet | o Indicator one-bit indicator to indicate whether extreme concise | |||
| follows. 1 - control packet; 0 - data packet. | format is used. 0 - NMP headers follows; 1 - undefined. | |||
| * Data/Control Headers Record the fileds of data packet header in | o NMP Headers Record the fileds of packet header in Section 4.1.1 . | |||
| Section 4.1.1 or the control packet header in Section 4.1.2 | ||||
| * Payload/MessageBody The payload of the data packet or message body | o Payload The payload of the packet. For control plane packets, the | |||
| of a control packet | control plane messages defined in Section 4.1.2 are carried in | |||
| this part. | ||||
| 4.1.1. Data Packet Header Format | 4.1.1. Data Packet Header Format | |||
| For data packet header, NMP uses bitmap with variable length to | For data packet header, NMP uses bitmap with variable length to | |||
| indicate which in-line headers appear in the packet. The | indicate which in-line headers appear in the packet. The | |||
| specification is in Figure 4. | specification is in Figure 4. | |||
| +----------------------+-------------------+ | +----------------------+-------------------+ | |||
| | Bitmap | In-line Headers | | | Bitmap | In-line Headers | | |||
| | (7 bits, extensible) | (variable length) | | | (7 bits) | (variable length) | | |||
| +----------------------+-------------------+ | +----------------------+-------------------+ | |||
| Figure 4: Data Packet Header Format | Figure 4: NMP Header Format | |||
| * Bitmap A variable-length bitmap with at least 7 bits is used to | o Bitmap A variable-length bitmap with at least 7 bits is used to | |||
| indicate whether a NMP field is carried in a packet.The value 1 | indicate whether a NMP field is carried in a packet.The bit of 1 | |||
| indicates that the packet carries this field and is located in the | indicates that the packet carries this field and is located in the | |||
| following in-line headers field. The value 0 indicates that the | following in-line headers field. The value 0 indicates that the | |||
| packet does not contain this field. The length of bitmap is | packet does not contain this field. The length of bitmap is | |||
| defined as follows. | defined as follows. | |||
| +------------------+----------------------------+-----------------+ | +------------------+----------------------------+-----------------+ | |||
| | bitmap format |number of bits for indicator|scope fo headers | | | bitmap format |number of bits for indicator|scope fo headers | | |||
| +------------------+----------------------------+-----------------+ | +------------------+----------------------------+-----------------+ | |||
| | 1xx xxxx | 6 bits | header 1 ~ 6 | | | xxx xxx0 | 6 bits | header 1 ~ 6 | | |||
| +------------------+----------------------------+-----------------+ | ||||
| |01x xxxx xxxx xxxx| 13 bits | header 1 ~ 13 | | ||||
| +------------------+----------------------------+-----------------+ | +------------------+----------------------------+-----------------+ | |||
| * In-line Headers The headers in NMP packet. Each header | o In-line Headers The headers in NMP packet. Each header | |||
| corresponds to a position in preceding bitmap. | corresponds to a position in preceding bitmap. | |||
| +--------+----------------+---------------+ | +--------+----------------+---------------+ | |||
| | Bitpos | Header Name | Header Length | | | Bitpos | Header Name | Header Length | | |||
| +--------+----------------+---------------+ | +--------+----------------+---------------+ | |||
| | 1 | Destination | Variable | | | 1 | TTL | 8 bit | | |||
| +--------+----------------+---------------+ | +--------+----------------+---------------+ | |||
| | 2 | Source | Variable | | | 2 | Total Length | 16 bit | | |||
| +--------+----------------+---------------+ | +--------+----------------+---------------+ | |||
| | 3 | Next Header | 8 bit | | | 3 | Next Header | 8 bit | | |||
| +--------+----------------+---------------+ | +--------+----------------+---------------+ | |||
| | 4 | Payload Length | Variable | | | 4 | Reserved | N/A | | |||
| +--------+----------------+---------------+ | +--------+----------------+---------------+ | |||
| | 5 | Checksum | 8 bit | | | 5 | Destination |Variable Length| | |||
| +--------+----------------+---------------+ | +--------+----------------+---------------+ | |||
| | 6 | DNS | 0 bit | | | 6 | Source |Variable Length| | |||
| +--------+----------------+---------------+ | +--------+----------------+---------------+ | |||
| | 7 ~ 13 | Reserved | / | | | 7 |Next Bitmap Byte| N/A | | |||
| +--------+----------------+---------------+ | +--------+----------------+---------------+ | |||
| 4.1.2. Control Packet Header Format | 4.1.2. Control Packet Format | |||
| +----------------------+-------------------+ | +----------------------+-------------------+ | |||
| | Type | Checksum | | | Message Type | Checksum | | |||
| | (7 bits) | (8 bits) | | | (8 bits) | (8 bits) | | |||
| +----------------------+-------------------+ | +----------------------+-------------------+ | |||
| Figure 5: Control Packet Header Format | Figure 5: Control Packet Header Format | |||
| * Type This filed carries value to indicate the type of this control | o Type This filed carries value to indicate the type of this control | |||
| message. | message. | |||
| * Checksum The checksum is the 8-bit one's complement of the one's | o Checksum The checksum is the 8-bit one's complement of the one's | |||
| complement sum of the entire control message, starting with the | complement sum of the entire control message, starting with the | |||
| message type field, and prepended with a "1" of indicator header | message type field, and prepended with a "1" of indicator header | |||
| fields, as specified in Section 4.1. For computing the checksum, | fields, as specified in Section 4.1. For computing the checksum, | |||
| the checksum field is first set to zero. | the checksum field is first set to zero. | |||
| 4.2. Control Messages | 4.2. Control Messages | |||
| 4.2.1. Address Request and Assignment Messages | 4.2.1. Address Request and Assignment Messages | |||
| A NMP host broadcasts an Address Request (AR) message to request an | A NMP host broadcasts an Address Request (AR) message to request an | |||
| address from the gateway of the NMP domain. The gateway sends an | address from the gateway of the NMP domain. The gateway sends an | |||
| Address Assignment (AA) message to the host to configure the host's | Address Assignment (AA) message to the host to configure the host's | |||
| NMP address. #### Format of Address Request The value of the message | NMP address. #### Format of Address Request The value of the message | |||
| Type is 0b000 0001. The message body is defined as follows. | Type is 1. The message body is defined as follows. | |||
| +-------------------+-----------+ | +-------------------+-----------+ | |||
| | ID length (8 bits) | Host ID | | | ID length (8 bits) | Host ID | | |||
| +-------------------+-----------+ | +-------------------+-----------+ | |||
| * ID length Length of this field is 1 octet. This header specifies | o ID length Length of this field is 1 octet. This header specifies | |||
| the length of the Host ID field, in octets. | the length of the Host ID field, in octets. | |||
| * Host ID Indicates the identifier of the host that accesses the NMP | o Host ID Indicates the identifier of the host that accesses the NMP | |||
| network. The identifier can be a MAC address or another globally | network. The identifier can be a MAC address or another globally | |||
| unique identifier. | unique identifier. | |||
| 4.2.1.1. Format of Address Assignment | 4.2.1.1. Format of Address Assignment | |||
| The value of the message Type is 0b000 0010. The message body is | The value of the message Type is 2. The message body is defined as | |||
| defined as follows. | follows. | |||
| +-------------------+---------+---------+-----------+--------+ | +-------------------+---------+---------+-----------+--------+ | |||
| |NMP Address Length | NMP | Gateway | ID length | Host ID| | |NMP Address Length | NMP | Gateway | ID length | Host ID| | |||
| | 8 bits | Address | Address | (8 bits) | | | | 8 bits | Address | Address | (8 bits) | | | |||
| +-------------------+---------+---------+-----------+--------+ | +-------------------+---------+---------+-----------+--------+ | |||
| * NMP Address Length Length of this field is 1 octet. This | o NMP Address Length Length of this field is 1 octet. This | |||
| parameter specifies the length of the NMP address used in the | parameter specifies the length of the NMP address used in the | |||
| local NMP domain. | local NMP domain. | |||
| * NMP Address Network layer address assigned to the host node. The | o NMP Address Network layer address assigned to the host node. The | |||
| length is specified by the NMP Address Length field. | length is specified by the NMP Address Length field. | |||
| * Gateway Address Network layer address of the gateway. The length | o Gateway Address Network layer address of the gateway. The length | |||
| is the same as length of NMP Address | is the same as length of NMP Address | |||
| * ID length Length of this field is 1 octet. This header specifies | o ID length Length of this field is 1 octet. This header specifies | |||
| the length of the Host ID field, in octets. | the length of the Host ID field, in octets. | |||
| * Host ID Indicates the identifier of the host that accesses the NMP | o Host ID Indicates the identifier of the host that accesses the NMP | |||
| network. The identifier can be a MAC address or another globally | network. The identifier can be a MAC address or another globally | |||
| unique identifier. | unique identifier. | |||
| 4.2.2. Address Lease Extension Messages | 4.2.2. Address Lease Extension Messages | |||
| To reduce the complexity of the NMP host, the gateway records the | To reduce the complexity of the NMP host, the gateway records the | |||
| lease information of each NMP address. When the lease of a host | lease information of each NMP address. When the lease of a host | |||
| address expires, the gateway sends a Renewal Challenge message to the | address expires, the gateway sends a Renewal Challenge message to the | |||
| host and waits for an response from the host. If a Renewal Response | host and waits for an response from the host. If a Renewal Response | |||
| message is received from the host, the lease information is updated | message is received from the host, the lease information is updated | |||
| based on the preconfigured strategy. Otherwise, the gateway releases | based on the preconfigured strategy. Otherwise, the gateway releases | |||
| the NMP address. | the NMP address. | |||
| 4.2.2.1. Renewal Challenge Message | 4.2.2.1. Renewal Challenge Message | |||
| The value of the message Type is 0b000 0011. The message body is | The value of the message Type is 3. The message body is defined as | |||
| defined as follows. | follows. | |||
| +-------------------+---------+-----------+--------+ | +-------------------+---------+-----------+--------+ | |||
| |NMP Address Length | NMP | ID length | Host ID| | |NMP Address Length | NMP | ID length | Host ID| | |||
| | 8 bits | Address | (8 bits) | | | | 8 bits | Address | (8 bits) | | | |||
| +-------------------+---------+-----------+--------+ | +-------------------+---------+-----------+--------+ | |||
| * NMP Address Length Length of this field is 1 octet. This | o NMP Address Length Length of this field is 1 octet. This | |||
| parameter specifies the length of the NMP address used in the | parameter specifies the length of the NMP address used in the | |||
| local NMP domain. | local NMP domain. | |||
| * NMP Address Network layer address assigned to the host node. The | o NMP Address Network layer address assigned to the host node. The | |||
| length is specified by the NMP Address Length field. | length is specified by the NMP Address Length field. | |||
| * ID length Length of this field is 1 octet. This header specifies | o ID length Length of this field is 1 octet. This header specifies | |||
| the length of the Host ID field, in octets. | the length of the Host ID field, in octets. | |||
| * Host ID Indicates the identifier of the host that accesses the NMP | o Host ID Indicates the identifier of the host that accesses the NMP | |||
| network. The identifier can be a MAC address or another globally | network. The identifier can be a MAC address or another globally | |||
| unique identifier. | unique identifier. | |||
| 4.2.2.2. Renewal Response Message | 4.2.2.2. Renewal Response Message | |||
| The value of the message Type is 0b000 0100. The message body is | The value of the message Type is 4. The message body is defined in | |||
| defined in Section 4.2.2.1. | Section 4.2.2.1. | |||
| 4.3. DNS Delegation Messages | 4.3. DNS Delegation Messages | |||
| Many IoT products are written into the domain name of the IoT service | Many IoT products are written into the domain name of the IoT service | |||
| platform when they are manufactured. The IP address of the server | platform when they are manufactured. The IP address of the server | |||
| needs to be obtained through the DNS to establish communication. | needs to be obtained through the DNS to establish communication. | |||
| Within the NMP domain, some modifications are required to traditional | Within the NMP domain, some modifications are required to traditional | |||
| DNS messages in [RFC1035]. The NMP host sends a DNS query packet to | DNS messages in [RFC1035]. The NMP host sends a DNS query packet to | |||
| the gateway. The Indicator field of the packet is set to 0, and the | the gateway. It Must set next header indicator to 1, the value of | |||
| DNS bit of the bitmap is set to 1. Destination of the packet is set | in-line next header is 17. Destination port in UDP header is 53. | |||
| to NMP address of gateway. When the gateway receives the packet, it | Destination of the packet is set to NMP address of gateway. When the | |||
| directly translates the network layer information and sends a regular | gateway receives the packet, it directly translates the network layer | |||
| DNS packet to the DNS server configured on the gateway. | information and sends a regular DNS packet to the DNS server | |||
| configured on the gateway. | ||||
| NMP is replaced by IPv6 protocol after the gateway. The source | NMP is replaced by IPv6 protocol after the gateway. The source | |||
| address is changed to 'IPv6 address prefix stored in the gateway + | address is changed to 'IPv6 address prefix stored in the gateway + | |||
| padding bit + NMP address', the destination address is changed to the | padding bit + NMP address', the destination address is changed to the | |||
| DNS server address configured on the gateway, and the payload | DNS server address configured on the gateway, and the payload | |||
| information remains unchanged. | information remains unchanged. | |||
| When the DNS response packet sent by the DNS server reaches the | When the DNS response packet sent by the DNS server reaches the | |||
| gateway, the gateway resolves the response packet and allocates an | gateway, the gateway resolves the response packet and allocates an | |||
| available NMP address to the destination IPv6 address. The NMP | available NMP address to the destination IPv6 address. The NMP | |||
| address is used as an in-network mirror of the IPv6 address and | address is used as an in-network mirror of the IPv6 address and | |||
| replaces the target address in the DNS response packet. Then, the | replaces the target address in the DNS response packet. Then, the | |||
| gateway sends the DNS response packet to the NMP host. | gateway sends the DNS response packet to the NMP host. | |||
| The header format of an DNS delegation message is defined as follows. | The header format of an DNS delegation message is defined as follows. | |||
| For details about the format of a DNS message body, see [RFC1035]. | For details about the format of a DNS message body, see [RFC1035]. | |||
| +-+---------+---------+---------+---------+------------+-----------+ | +-+---------+---------+---------+---------+------------+-----------+ | |||
| |0| 1111111 | gw addr | NMP src | Nxt Hdr | pld length | hchecksum | | |0| 0110110 | Total Length | Nxt Hdr | GW Addr | NMP src | | |||
| +-+---------+---------+---------+---------+------------+-----------+ | +-+---------+---------+---------+---------+------------+-----------+ | |||
| | UDP header | | | | UDP header(port=53) | | | |||
| +---------------------+ + | +---------------------+ + | |||
| | | | | | | |||
| | DNS message body defined in RFC 1035 | | | DNS message body defined in RFC 1035 | | |||
| | | | | | | |||
| +------------------------------------------------------------------+ | +------------------------------------------------------------------+ | |||
| 4.4. Functionalities of Gateway | 4.4. Functionalities of Gateway | |||
| 4.4.1. Address Management | 4.4.1. Address Management | |||
| The NMP gateway initializes the NMP address pool based on the network | The NMP gateway initializes the NMP address pool based on the network | |||
| configuration and assigns an address to itself. This address is used | configuration and assigns an address to itself. This address is used | |||
| as the default gateway by the hosts in the domain. | as the default gateway by the hosts in the domain. | |||
| Intra-domain address management functionaliteis includes: * intra- | Intra-domain address management functionaliteis includes: * intra- | |||
| domain host address allocation The gateway listens to the NMP address | domain host address allocation The gateway listens to the NMP address | |||
| request message, allocates the corresponding NMP address based on the | request message, allocates the corresponding NMP address based on the | |||
| message content, generates an address assignment message, and returns | message content, generates an address assignment message, and returns | |||
| the message to the host. The assigned addresses must meet the | the message to the host. The assigned addresses must meet the | |||
| uniqueness requirements within the NMP domain. * intra-domain host | uniqueness requirements within the NMP domain. * intra-domain host | |||
| address life cycle management The gateway manages the validity period | address life cycle management The gateway manages the validity period | |||
| of NMP addresses. The lease renewal challenge mechanism is used to | of NMP addresses. The lease renewal challenge mechanism is used to | |||
| renew or release host addresses. | renew or release host addresses. | |||
| 4.4.2. Address Translation | 4.4.2. Address Translation | |||
| The NMP address space can be mapped to specific subspaces of IPv6 | The NMP address space can be mapped to specific subspaces of IPv6 | |||
| address space. When traffic is destinated to a destination outside | address space. When traffic is destinated to a destination outside | |||
| the domain, the gateway translates the host address (source address) | the domain, the gateway translates the host address (source address) | |||
| in the domain into an IPv6 address. For details about the | in the domain into an IPv6 address. For details about the | |||
| skipping to change at page 10, line 34 ¶ | skipping to change at page 10, line 42 ¶ | |||
| If NMP is running on Ethernet, a new Ethtype is required. In | If NMP is running on Ethernet, a new Ethtype is required. In | |||
| addition to Ethernet, other link-layer protocols that need to carry | addition to Ethernet, other link-layer protocols that need to carry | |||
| multiple upper-layer protocols need to assign specific identifiers to | multiple upper-layer protocols need to assign specific identifiers to | |||
| NMP to instruct devices to process network-layer packets according to | NMP to instruct devices to process network-layer packets according to | |||
| this document. | this document. | |||
| This document requires to define new registry for NMP control message | This document requires to define new registry for NMP control message | |||
| types, six of which are defined in this document. | types, six of which are defined in this document. | |||
| 8. Normative References | 8. Acknowledgments | |||
| The authors would like to acknowledge the contributions Guangpeng Li | ||||
| and Zhaochen Shi provided during the development of the solution. | ||||
| 9. Normative References | ||||
| [RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
| specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
| November 1987, <https://www.rfc-editor.org/info/rfc1035>. | November 1987, <https://www.rfc-editor.org/info/rfc1035>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| skipping to change at page 11, line 14 ¶ | skipping to change at page 11, line 28 ¶ | |||
| [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. | [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. | |||
| George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, | George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, | |||
| DOI 10.17487/RFC7010, September 2013, | DOI 10.17487/RFC7010, September 2013, | |||
| <https://www.rfc-editor.org/info/rfc7010>. | <https://www.rfc-editor.org/info/rfc7010>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| Author's Address | Authors' Addresses | |||
| Sheng Jiang | Sheng Jiang | |||
| Huawei Technologies | Huawei Technologies | |||
| Beiqing Road, Haidian District | Beiqing Road, Haidian District | |||
| Beijing | Beijing 100095 | |||
| 100095 | P.R. China | |||
| China | ||||
| Email: jiangsheng@huawei.com | Email: jiangsheng@huawei.com | |||
| Zhe Chen | ||||
| Huawei Technologies | ||||
| Beiqing Road, Haidian District | ||||
| Beijing 100095 | ||||
| China | ||||
| Email: chenzhe17@huawei.com | ||||
| End of changes. 56 change blocks. | ||||
| 84 lines changed or deleted | 89 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||