| Next header | Length of extension header | |
|---|
| Option |
Next header: Bit selector. This is an identifier type of header that follows the destination option header. Use the same value as the IPv4 [RFC-1700].
Length of extension header: It is an 8-bit unsigned integer. The destination option header length is in 8-bit groups, and does not contain the first 8-bit group.
Option: It’s a Variable length field, whose length makes the destination option header length an integer multiple of 8-bit group. It contains one or more TLV encoding options.
Optional destination information in IPV9 packets is encoded in two ways: defined in the destination options header, or as a separate extended header. Data segment headers and authentication headers are two examples of the latter. Which one to take is depends on the action if the destination node could not recognize the option information.
a)
If the destination node operation is want to abandon packets, and only in the destination node address of the packet is not the multicast address, then send the packet source address a “ICMP Unrecognized Type” message, and then these messages can be encapsulated into a separate header, or destination option in a header option, and the highest two digits of the option type are 11. This choice depends on a number of factors, such as fewer bytes, better alignment, or easy to parse.
b)
If both operations are required, the messages must be encoded as an Option at the head of the destination Option, whose Option type has a highest two digits is 00, 01, or 10, specifying which actions will be take.
Note: When the next header field of an IPV9 header or any extended header is 59, which means there’s nothing behind the header. If the IPV9 header payload length field indicates that there are 8-bit groups after the next header field of 59, these 8-bit groups must be ignored, and the content is passed as is when the packet must be forwarded.
III. PACKET LENGTH DESIGN
IPV9 requires a minimum of 576 MTU per link on the Internet. On any link, if it cannot pass 576 8-bit groups in one packet, then the data segment and reassembly associated with the link must be supported by the hierarchy below IPV9.
For each link directly connected to the node, the node must be able to accept packets as large as MTU. Links with configurable MTU (such as PPP links [RFC-1661]) must be configured with at least 576 8-bit groups, and larger MTU is recommended to accommodate possible encapsulations (such as tunnels) without fragmentation.
IPV9 nodes are recommended to implement Path MTU Discovery [RFCc-1191] in order to discover and take advantage of MTU links larger than 576. However, a minimal IPV9 implementation (such as in a BootROM) can simply restrict itself from sending packets larger than 576 and omit the Path MTU Discovery implementation.
In order to send MTU packets with a length greater than the link, the node can segment the packet at the source node and assemble it at the destination node by using the data segment header of IPV9. However, this fragmentation is not recommended in any application unless it can resize packets to fit the MTU of the link being measured.
A node must be guaranteed to accept segmented packets that exceed 1500 bytes after reassembly, including IPV9 headers. However, a node must ensure that it does not send segmented packets larger than 1500 bytes after reassembly unless it is explicitly told that the destination node can assemble such a large packet.
When sending an IPV9 Packet to an IPv4 node (that is packets go through the transition from IPV9 to IPv4)), the IPV9 source node may receive an “ICMP Packet TOO Big” (ICMP Packet is TOO Big) message reporting that next-hop MTU must be less than 576. In this case, IPV9 does not need to reduce the size of subsequent packets to less than 576, but must include a segment header in those packets so that the IPV9-IPv4 conversion router can obtain an appropriate identifier value for the constructed IPv4. This means that the load can be reduced to 496 8-bit groups (576 minus 72 bytes for IPV9 headers and 8 bytes for data segment headers) or even smaller if additional extended headers are used.
In order to send MTU data packets whose length is longer than the link, such as audio, image and video, long-stream code and absolute return code can be selected. The node can use the data segment header of IPV9 to identify the data packets in the source node without segmentation and assemble them in the destination node. However, when the sender and the receiver receive the signal disconnected by the return code, they will return to normal working condition.
Note: unlike IPv4, IPV9 does not require a “Don’t Fragment” flag in the packet header to perform Path MTU Discovery, which is an implicit feature of IPV9. And the process associated with using MTU in RFC-1191 is not applicable to IPV9, because the message of IPV9 “Datagram Too Big” is always identifies the exact MTU being used.
Also, the procedures associated with the use of MTU tables in rfc-1191 are not applicable to IPV9 because the IPV9 version of the “Datagram Too Big” message always identifies the exact MTU being used.
Unlike IPv4 and IPv6, IPV9 can transmit the practical applications such as audio or video, it need to use the ever-flowing code and absolute return code, thus formed in the reserved the actual circuit actually has become a three layer structure, so there is no try to transfer the concept of content as guaranteed delivery channels and reliable safety, guarantee the transmission content don’t interrupt. This results in the co-existence of the three - and four-tier architectures within the IPV9 network.
IV. FLOW LABEL
A data flow is a sequence of packets sent from one source to another destination address (point-to-point or multicast), and the source nodes require the intermediate router to have special control over these packets. These special processes can be transferred to routers through control protocols, such as resource reservation protocols, or through the information carried by the packets themselves in the data stream, such as segment options.
There may be multiple active streams between a pair of source and destination nodes, as well as many communications independent of any flow. A flow is uniquely identified by a combination of a source address and a non-zero flow label. The flow label field for packets that do not belong to any flow is set to 0.
The flow label is assigned by the source node of the data flow. New flow tags must be randomly selected (pseudo random), ranging from 1 to 16777215 (decimal). The purpose of the random assignment is to make the bits in the flow label suitable for use as hash keys in routers to find the relevant state of the flow.
All packets belonging to the same flow must be sent with the same source node address, destination node address, priority, and flow label. If any of these packets contain a segment option header, they must all have the same segment option header content. If any of their packets contain a routing header, all of their extended headers preceding the routing header must have the same content, including the routing header (except for the header field next to the routing header). Allows, but does not require, the router and destination node to check whether the above requirements are met. If a collision is detected, it should sending “ICMP parameter has a problem, code 0” message and then pointing to the high bit of the flow label (i.e., within the IPV9 packet with an offset of 1).
Routers are free to set the flow control state of based on “timing” even when there is no explicit flow control protocol, segment options, or other methods provide them with flow creation information. For example, when a flow label with an unknown, non-zero label is received from a particular source node, the router can process its IPV9 header and any other necessary extension headers as if the flow control label were 0.
The flow control state described above, after being set and cached according to “timing” must be discarded within 6 seconds, whether or not packets of the same class continue to arrive. If another packet with the same source address and flow control label arrives after the cache state has been discarded, then the packet must undergo full normal processing (as if the flow control label is 0), this process may cause the flow control state of the flow to be re-established and cached.
The lifetime of explicitly established flow control states, such as flow control states created by control protocols or segment options, must be specified as part of the explicit establishment mechanism and can exceed 6 seconds.
During the lifetime of any flow control state that was previously created, the source node must not use this control label for new flows. Since any flow control state created depending on “timing” has a lifetime of six seconds, the minimum time between the last packet of a flow and the first packet of a new flow to use the same flow label is six seconds. The flow label has a longer lifetime and cannot be reused for new flows during the lifetime.
When a node is off and restarted (for example due to a system crash), care must be taken to avoid using flow label that it might have used for previously created flow that have not yet expired.
This can be achieved by record flow label in the memory, so that it can recall flow label previously used after a system crash, or until the previously created, there may be one of the biggest lifetime timeout before does not use flow label (at least for 6 seconds, if it use an explicit flow and establish a mechanism, and specifies the longer life span, even longer time). If the reboot time of a node is known (usually more than 6 seconds), the amount of time to wait before starting to allocate flow tags can be deducted accordingly.
V. CATEGORY TYPE DESIGN
The 8-bit Category Type field in the IPV9 header enables the source node to identify the desired level of packet delivery determination, certainly relative to other packets sent from the same node. Category Type bits contain two parts: 3 bits high is used to specify the address length, the value is 0 ~ 7, is 2 to the power, the address length is 1Byte ~ 128Byte; the default value is 256 bits, where 0 is 16 bits, 1 is 32 bits, 2 is 64 bits, 3 is 128 bits, 4 is 256 bits, 5 is 512 bits, 6 is 1024 bits, and 7 is 2048 bits. The last five bits specify two ranges of communication categories, with values 0 ~ 7 used to specify the information priority provided by the source node for congestion control, that is, the priority of information sent with a delay in the face of congestion, such as TCP information. 8 ~ 15 are used to specify the priority of messages that are sent without delay in the face of congestion, that is, the priority of “real time” packets that are sent at a fixed rate.
For crowd-constrained information, the following priority values can be used for specific application classes.
0: Non-character information,
1: Fill in the information (such as: net news),
2: Unattended information (such as: Email),
3: Reserve,
4: Large quantities of supervised information (such as: FTP, NFS),
5: Reserve,
6: Interactive information (such as: Telnet, X),
7: Internet control information (Such as: Routing protocol, SNMP),
8: For audio,
9: For video,
10: For video or audio compression will not be error due to alignment error,
11: Broadcast with audio and video,
12: Emergency use.
For messages that are not congested, the lowest rating value of 8 should be used for packets that the sender most wants to discard in crowded conditions (such as high-fidelity video messages), and the highest rating value of 15 should be used for packets that the sender least wants to discard (such as low-fidelity audio messages). There is no corresponding sequential relation between the rank of un-crowded and the priority of crowded.
VI. UPPER PROTOCOL DESIGN
A. Upper protocol check
If any transport protocol or other upper layer protocol includes the address in the IP header when calculating its checksum, then in order to be able to run on IPV9, the algorithm that calculates the checksum must be modified to include addresses with a length of 16-2048 bits rather than 32-bit IPv4 addresses. TCP and UDP headers for IPV9 are shown in table 11.
TABLE XI.
TCP AND UDP HEADERS FOR IPV9
| Source address |
| Destination address |
| Time |
| Identify code |
| Payload Length |
| 0 | Next header |
1)
If the packet contains the routing header, the destination address in the pseudo-header is the final address. In the source node, this address is the last address in the routing header; at the receiver, this address will be in the IPV9 header address field.
2)
The value of the next header in the pseudo-header identifies the upper protocol (e.g., TCP is 6, UDP is 17). If there is an extended header between the IPV9 header and the upper protocol header, the value of the next header in the pseudo-header is different from the value of the next header in the IPV9 header.
3)
The value of the load length field in the pseudo-header is the length of the upper protocol packet, including the upper protocol header. If there is an extended Payload between the IPV9 Payload and the upper protocol Payload it will take less Payload Length than the IPV9 Payload Length (or in the large Payload option).
4)
Different from IPv4, when a UDP packet is sent from an IPV9 node, UDP checksum is not optional. That is, whenever an IPV9 node sends a UDP packet, it must calculate the UDP checksum. The checksum is generated by the packet and pseudo-header, and if the result is 0, it must be converted to hex FFFF and placed in the UDP header. The IPV9 receiver must abandon the UDP packet containing the checksum 0 and record the error.
The checksum of ICMP version of IPV9 includes the above pseudo-header in its verification and calculation. This is a modification of the IPv4 version of ICMP, which does not include a pseudo-header in its verification and calculation. This change is made to ensure that ICMP is not passed incorrectly or corrupted by the IPV9 header fields on which it depends, which, unlike IPv4; these fields are not checked and protected by the Internet layer. The next header field in the pseudo-header of ICMP contains the value 58, which identifies the IPV9 version of ICMP.
B. Maximum packet lifetime
Unlike IPv4, IPV9 nodes like IPv6 do not require a mandatory maximum packet lifetime. This is why the “lifetime” field of IPv4 has been renamed IPV9’s “segment limit”.
In practice, very fewer IPv4 complies with the current packet lifetime, so this is not a practical change. Any protocol that relies on the Internet layer (whether IPV9 or IPv4) to limit the lifetime of packets should be upgraded to rely on its own mechanism to detect and discard stale packets.
C. Maximum upper layer load
When calculating the maximum load available for upper level protocol, it must be taking into account that the IPV9 header is larger than the IPv4 header.
For example, in IPv4, TCP’s MSS option is calculated by the maximum datagram length (the default value obtained through Path MTU Discovery) minus 40 8-bit groups (20 8-bit groups for the minimum length of IPv4 headers and 20 for the minimum length of TCP headers) from.
When using TCP over IPV9, the MSS must be calculated by the maximum length minus 60 8-bit groups, because the minimum IPV9 header (when IPV9 without an extended header) is 20 8-bit larger than the minimum IPv4 header.
VII. FORMAT OF OPTIONS
It is required to design the fields first when designing new options for segment option headers or destination option headers; these are based on the following assumptions.
1)
Any field in the option data of an option that consists of multiple 8-bit groups should be aligned with their natural boundaries, that is, fields with n 8-bit groups of width should be placed at integer multiples of n 8-bit groups from the beginning of the segment header or destination option header, where n= 1,2,3,4 or 8.
2)
Each segment header or destination option header takes up as little space as possible and must meet the requirement that the header length is an integer multiple of an 8-bit group.
3)
It can be assumed that when any header with options appears, they only have a fewer options, usually only one.
These assumptions mean that it needs planning the individual fields of an option, arrange the fields from smallest to largest, with no padding in the middle, and then derive the alignment requirements for the entire field based on the alignment requirements for the largest field.
Examples are given below.
Case1. If option X requires two data fields, one with a length of 8 8-bit groups and one with a length of 4 8-bit groups, it should be arranged according to table 12.
TABLE XII.
| Option Type =X | Option data length =12 |
|---|
| Four 8-bit group fields |
| Eight 8-bit group fields |
Its alignment requirement is 8n+2 to ensure that the eight 8-bit fields start with an 8-fold offset from the header. The full segment header or destination header with the above options is shown in table 13.
TABLE XIII.
FULL HEADER OR DESTINATION HEADER FORMAT
| Next header | length of extension header =1 | Option Type =X | Option data length =12 |
|---|
| Four 8-bit group fields |
| Eight 8-bit group fields |
Case 2. If option Y requires three fields, one with a length of four 8-bit groups, one with a length of two 8-bit groups, and one 8-bit group, the format is shown in table 14.
TABLE XIV.
THREE FIELD DESIGN FORMAT
| | Option Length=Y |
| Option data length =7 | One 8-bit group fields | Two 8-bit group fields |
| Four 8-bit group fields |
Its alignment requirement is 4n+3 to ensure that the four 8-bit leader fields start at a 4 times offset from the header. The full hop-by-hop or destination option header with the above options is shown in table 15.
TABLE XV.
A THREE-FIELD FULL DATA FORMAT
| Next header | length of extension header =1 | Pad1 option =0 | Option Type =Y |
| Option data length =7 | One 8-bit group field | Two 8-bit group fields |
| Four 8-bit group fields |
| PadN option=l | Option data length =2 | 0 | 0 |
Case 3. The segment header or destination header for each option X and option Y in both case 1 and case 2 should be one of the following two formats, depending on which option appears first, as shown in tables 16 and 17.
TABLE XVI.
ONE FORMAT OF CONTAIN BOTH TWO- AND THREE-FIELD ADDRESS
| Next header | length of extension header =3 | Option Type=X | Option data length =12 |
|---|
| Four 8-bit group fields |
| Eight 8-bit group fields |
| PadN Option =1 | Option data length =1 | 0 | Option Type=Y |
| Option data length =7 | One 8-bit group fields | Two 8-bit group fields |
| One 8-bit group fields |
| PadN option=l | Option data length =2 | 0 | 0 |
TABLE XVII.
ANOTHER FORMAT OF CONTAIN BOTH TWO- AND THREE-FIELD ADDRESS
| Next header | length of extension header =3 | PadN option=l | Option Type=Y |
|---|
| Option data length =7 | One 8-bit group fields | Two 8-bit group fields |
| Four 8-bit group fields |
| PadN option=l | Option data length =4 | 0 | 0 |
| 0 | 0 | Option Type =X | Option data length =12 |
| Four 8-bit group fields |
| Eight 8-bit group fields |
VIII. ENCAPSULATE SECURITY PAYLOAD HEADER DESIGN
A. Format of encapsulate security payload header
ESP (Encapsulating Security Payload) Header is designed to provide mixed security services in IPv4. The ESP mechanism can be applied with the authentication header or in a nested manner in tunnel mode alone. Security services may be provided between a pair of communicating hosts, or between a pair of communicating security gateways, or between a security gateway and a host.
The primary difference between the authentication header and the ESP mechanism is the effective area service. The encapsulation security payload mechanism does not protect any IP header fields unless they are encapsulated by the ESP, such as in tunnel mode where the IP header is encapsulated underneath.
The encapsulation security header is inserted after the IP header. In transport mode, the encapsulated security header is in front of the upper layer protocol header, and in tunnel mode, the encapsulated security header is in front of the encapsulated IP header.
ESP mechanisms provide services such as confidentiality, data origin authentication, connectionless integrity, anti-replay services (a form of partial sequence integrity), and limited communication confidentiality. The business provided by this mechanism depends on the options and the location of the application when the security association is established.
Confidentiality can be independent of other business options. However, the use of confidentiality alone without integrity authentication can lead to attacks that compromise the confidentiality of communication. Data origin authentication and connectionless integrity are federated services that can be provided as an option along with confidentiality services. The anti-replay service can only be selected if the data origin authentication service is selected, which is entirely up to the receiver.
The confidential service requires selection in tunnel mode, and this service is most effective when it used in the security gateway, because the clustering of communication on the gateway may mask the true source and host address modes. Note that while both confidentiality and authentication services are optional, at least one of them should be chosen.
A protocol header (IPv4 header, IPV9 base header, or extended header) that precedes the ESP header will have a value of 50 in its protocol field (if IPv4 header) or in its next header field (if it is the IPV9 extended header). The format of ESP groups and headers is shown in table 18.
TABLE XVIII.
FORMAT OF ESP GROUPS AND HEADERS
| 0 8 16 24 31 |
| Security Parameters Index (SPI) |
| Sequence Number |
| Payload Data (variable length) |
| Fill field (0~255B)) |
| Pad Length | Next Header |
| Authentication Data (variable length) |
Note: the scope of the certification business is the part before the certification data (authentication data is not included); the scope of the encryption service provided is the portion of the data that follows the serial number and precedes the authentication data (Serial Numbers and authentication data are not included).
B. Description of safe load format
The fields in the header format are explained below. The “optional” of the text indicates that if the field is not selected, the field is ignored and is not used when calculating the overall check value. If “required”, this field must appear in the ESP group.
1). Security Parameters Index (SPI)
It is a required field of 32 bits. This field is associated with the security of the datagram that uniquely identifies the address of the address IP and the security protocol. The value of the SPI can be any, currently from 1 to 255 is reserved by IANA (). The value 0 of SPI is reserved for local, specific application use.
2). Sequence Number
It is a 32bit monotonically increasing counter (serial number). This field is required even if the receiver does not select to enable the playback service for a particular security association. The processing of this sequence number field is entirely done by the receiver, that is, the sender must transmit this field, and the receiver may or may not comply with the field.
When a security association is established, both sender and receiver counters are set to 0. If the anti-replay is started (default is enabled), the serial number transferred does not allow loops. Therefore, after a secure association group, the sender and receiver counters must be reset.
3). Payload Data
It is a variable-length field that contains the data described by the next header field. The payload field is required and is an integer multiple of bytes in length.
4). Fill field
This field is used for encryption. The purposes of use fill fields in the ESP header are as follows.
a)
If an encryption algorithm requires the body to be an integer multiple of bytes, the padding bytes are used to the body. (In addition to the filling fields themselves, the payload data, the filling length, and the next header fields are also included) to meet the data length requirements of the encryption algorithm.
b)
Even without considering the requirements of the encryption algorithm, fields need to be filled in to ensure the length of the encrypted data terminates at the boundary of 4B. In particular, the length of the fill length field and the next header field must be aligned to 4B.
c)
Apart from above algorithmic and alignment requirements, padding fields may also be used to hide the true length of the payload and partially encrypt the communication. However, this additional padding obviously consumes bandwidth resources and should be used with caution.
The sender can add 0 to the 255B to the fill field. Padding is optional in an ESP group, but all applications must support the generation and use of padding fields to satisfy the encryption algorithm for the length of the encrypted data while ensuring that the authentication data is aligned to the 4B boundary.
d)
Pad Length
This field is required, and the valid fill length value should be from 0 to 255, with 0 indicating no fill bytes.
e)
Next header
This field is required and is an 8-bit field indicating the data type in the payload data field.
f)
Authentication Data
It is a variable-length field that contains the group’s Integrity Check Value (ICV), which is calculated from the ESP group except the authentication data. This field is optional and only occurs if the authentication business is included in the security association. The authentication algorithm must account for the full length of the verification value and the relative rules of validation and processing steps.
C. Processing of security payload header
Encapsulated security payloads (ESP) are used in two ways: transport mode or tunnel mode.
1). Transmission mode
Transmission mode applies only to host applications. In this mode, the ESP header only protects the upper layer protocol and not the IP header field. In this mode, the ESP header is inserted after other IP headers and before the upper layer protocols of TCP, UDP, and ICMP. In IPV9, the ESP header is treated as an end-to-end payload, so the header must appear after the hop-to-hop, route, and segment headers.
The host option header may appear before or after the ESP header, depending on the semantics required. The locations of the ESP headers in a typical IPV9 packet in transport mode are shown in tables 19 and 20.
TABLE XIX.
DATAGRAMS BEFORE THE APPLICATION OF ESP HEADER
| Basic header | Extension header (if any) | TCP | Data |
TABLE XX.
DATAGRAM AFTER THE APPLICATION OF ESP HEADER
| Basic header | Hop-to-hop, Destination header Route header Segment header | ESP | Destination Options header | TCP | Data | ESP Trailer | ESP authentication |
The encrypted portion of the above packet can be a basic header encryption or a host option header, TCP, data, and ESP tail. The authenticated part in addition to the above part is encrypted, but also the package security load.
2). Tunnel mode
The ESP header in tunnel mode can be used for host or security gateway. Tunnel mode must be used when the ESP header is applied to the security gateway to protect the user’s transmission communication.
In tunnel mode, the “lower” IP header carries the final source and destination address, while the “upper” IP headers contain the other addresses, such as the address of a security gateway.
In tunnel mode, the ESP header is positioned relative to the “upper” IP header as it is in transport mode. The position of the ESP header in a typical IPV9 packet in tunnel mode is shown in table 21.
TABLE XXI.
ESP HEADERS IN TYPICAL IPV9 PACKETS IN TUNNEL MODE
| upper Basic header | Upper Extension header (if any) | ESP | lower Basic header | Upper Extension header (if any) | TCP | Data | ESP Trailer | ESP authentication |
In the above group, the encrypted part can be the upper basic header, the lower basic header, the lower extended header, TCP, data and ESP. The authenticated part in addition to the above part is encrypted, but also the ESP.
IX. CONCLUSION
This paper is a specific research and design scheme of RFC1606 and RFC1607 for the future network. The 42-layer routing address space is described according to the document in RFC1606. IPV9 has a routing hierarchy of up to 42 layers, and this routing hierarchy is a key feature in its wide application.
In order to protect previous investments, IPv4 and IPv6 compatible addresses have been set inside, with layers 1-41 designed for IPv4 and IPv6 compatibility and layer 42 described in the RFC1606 document. The large number of address Spaces in IPV9 also makes it possible to allocate addresses in a direct way
In order to the application of IP mobile, IPTV, IP phone, Internet of things and other network applications that need to use Arabic numerals to represent and need to use characters that do not have to be analyzed again, this design also designed a character router.
IPV9 address length is designed according to the document of RFC1607 that the network address length is 1024 bits in the future network, and the address space length is designed as 2048 bits according to the actual demand, thus solves the address space capacity problem in the next 750 years.
In order to meet the technical demand of RFC1606 and RFC1607, the definitions of routing hierarchy, address length, address working mode, address space resource, address text representation method, compression definition and separator were redefined, Please refer to other related articles of this design team.
