Research on the Application of mobile communication nodes in IPv6

A communication node is any node that communicates with a mobile node. It can be static or mobile. The mobile node can notify the current location of the communication node, which is completed through the communication binding process.

As part of this process, in order to authorize the binding establishment, we need to test the returned path accessibility. When sending data packets to any IPv6 destination, the node must check whether there is a record of the destination address in its own binding cache. If a record with a destination address exists, the node uses a new route header to send data packets to the forwarding address in the binding; otherwise, the node sends data packets in the usual way, this packet will be sent to the owner proxy, the owner proxy intercepts this packet, and then sends this packet to the mobile node through a tunnel. This process is described in detail.

1. concept description of mobile communication nodes

Each IPv6 node maintains a binding cache for other nodes. Each IPv6 node maintains an independent binding cache for each IPv6 address; each "Bind Cache" entry should contain the following domains.

1. mobile Node attribution address: this domain is used to search for a primary key of the destination address of the sent data packet in the binding cache. If the destination address of the data packet matches the attribution address in the bound cache entry, this entry should be used to route this data packet.

2. transfer address of the mobile node: In the bound cache entry, the transfer address of the mobile node is associated with the address domain; if the destination address of a data packet routed by a node matches the destination address in the entry, the data packet should be routed to the forwarding address.

3. survival time: the value of the survival time domain indicates the remaining survival time of a bound cache entry. The value of the survival time domain is initialized by the generation or final modification of the bound cache entry's bound and updated survival time domain, once the lifecycle of an entry expires, the entry must be deleted from the bound cache.

4. Flag domain: indicates whether the bound cache entry is a registered entry.

5. Maximum number of serial number domains in the bound update received from the mobile node attribution address: the length of the serial number domain is 16 bits.

6. recently used information for binding cache entries: this information must be used to bind and replace a cache, it also helps determine whether to send a binding update request when the survival time of an entry approaches termination.

A bound cache entry not marked as registered can be replaced at any time based on a feasible local cache replacement policy, but it should not be deleted for unnecessary reasons. In the cache bound to any node, a maximum of one cache is maintained for the owner address of each mobile node. The content bound to the cache of a node cannot be changed according to the option of the address of the received data packet. When a node restarts, all the content bound to the cache entry of the node must be cleared.

Ii. receive data packets from mobile nodes

The communication node must specially process the data packets sent from the mobile node with the option of the destination address or the mobile header:

1. process the mobile header (MH) Message

All IPv6 communication nodes must comply with the following rules when processing mobile header (MH) messages:

* If an unknown type of MH message is received, the communication node should send a binding error message to the source address of the data packet, with the status Domain value set to 2. The communication node must discard this data packet.

* If the value of the next header field is not NO_NXTHDR (59), the packet should be quietly discarded.

Subsequent checks depend on specific mobile header messages. There are two types of mobile header messages. The returned path accessibility process is used to verify the active locations of the mobile nodes and the transferred addresses. This detection helps to ensure the security of binding updates; another type of mobile header message is directly used to manage bindings.

2. receive data packets with the option of the destination address

If the communication node has a bound cache entry for the mobile node's attribution address, the data packet sent by the mobile node may contain a attribution address option. When a communication node receives a packet containing the attribution address option, it must process this option, copy the attribution address domain in this option to the IPv6 packet header, and replace the initial value of the source address. After the option carried by the data packet is processed, the subsequent processing steps of the data packet do not need to know whether the original source address is the forwarding address or the attribution address. For a data packet that includes the Binding Update message and owner address options, if the Binding Update is successfully created or updated, the bound cache entry can be considered to have passed the preceding check.

If a packet passes the test above, it is discarded. Then, the communication node should send a one-person binding error message to the source address of the packet containing the owner address option. The value of the Status field in the message should be set to 1. The sending rate of these messages should be limited.

Generally, you do not need to perform additional authentication on the owner address option. However, if the IPv6 packet header of the data packet is covered by the authentication, this authentication must also overwrite the owner address option, this overwrite is automatically implemented by defining the option type encoding in the owner address option. This encoding specifies that the data cannot be modified before the data packet reaches the destination, therefore, this option is included in the scope of certification calculation. Because the authentication of IPv6 headers overwrites the attribution address option, the advent of the attribution address option does not reduce the security of the source address domain in IPv6 headers. When trying to verify the authentication data in a packet containing the attribution address option, the receiving node must assume that the address in the attribution address option is the forwarding address, while the source address in the IPv6 packet header is the attribution address.

3. Determine whether the selected route is reachable

When determining whether the selected route is available, it mainly includes the following actions.

1. receive the initial message of the attribution test.

When receiving the initial message of the attribution address test, the communication node should perform the following test:

* The value of the MH type field of the message is 1;

* Data packets must not contain the option of the destination address.

Before sending a Test message to the desired VPC address, the communication node should check whether it has the elements required for the return path accessibility process. The communication node must have a Kcn key and a temporary random number N1. If the communication node does not have these two elements, it must be converted into Kcn and N1 before continuing the process of returning to the path.

2. receive the initial message from the transfer address

When receiving the initial message for the transfer address test, the communication node should perform the following test:

* The value of the MH type field of the message is 2;

* Data packets must not contain the option of the destination address.

Before sending a forwarding address Test message. The communication node should check whether it has elements required for the return path accessibility process. The returned path is reachable. The communication node must have a key Kcn and a temporary random number N1. If the communication node does not have these two elements, it must be converted into Kcn and N1 before continuing the process of returning to the path.

3. Send the attribution address Test message

If the communication node does not create a transfer Cookie and a temporary random number associated with it, it must first create them. Then you can create a attribution address Test message and send it to the mobile node's latest attribution address.

4. Bind the destination address in the cache

The binding cache messages processed by the Communication Node include binding updates, binding update requests, and binding confirmation.

1. Receive binding updates

Before receiving the bound update message, a node must perform the following steps to check the validity of the bound update message;

* This package must contain an owner address option.

* If you have received an update bound to the same owner address, the value of the serial number field in the received update message must be greater than the value of the serial number field in the previously received update bound. The serial number can be compared only after the modulo operation of 65536 is performed. If the serial number in the received bound update is within the range of the serial number in the previously received bound update, the serial number is considered to be less than or equal to the serial number received recently, this is also true for a value that exceeds 32767.

If the serial number in the Binding Update sent by the mobile node is less than or equal to the serial number in the latest successful Binding Update, the receiving node must send a binding confirmation with the status code 141, enter the recently accepted bound update serial number in the serial number field in the binding confirmation.

If the index value of the ownership or transfer temporary random number sent by the mobile node is no longer recognized by the communication node, the receiving node must send a status code of 144 or 145 for confirmation.

All binding updates that do not meet these checks for other reasons (except for the serial number or the index value of the temporary random number is small) must be ignored and packets carrying these binding updates must be discarded.

2. Request a cache binding

This article describes the binding process of a mobile node cached by the request node for effective binding update. In this binding update, the owner registration position (H) is not set. In this case, the receiving node should generate a new cache entry for the mobile node in its binding cache. If such an entry already exists, then the bound cache entries of the current mobile node should be updated. The survival time of the bound cache entry comes from the survival time domain bound to the update. caching the bound node may reduce the survival time; the survival time of the bound cache entry must not be greater than the specified time value in the bound update. When the survival time of the bound update entry expires, the bound entry must be deleted.

The value of the serial number in the bound update received by the mobile node is stored in the bound cache entry of the mobile node in the Communication Node. If the mobile node does not have a bound cache entry, the communication node must accept the value of any serial number in the bound update received from the mobile node.

3. Request to delete a binding

This article describes the binding and updating process of a mobile node from the binding cache by the request node. In this binding and updating process, the owner registration location (H) is not set. In this case, the receiving node must delete any entries related to the mobile node in the binding cache. When receiving such a binding update, the communication node cannot generate a binding cache entry for the mobile node.

If a cache entry is created and bound by the return path, the communication node must ensure that temporary random numbers of specific attribution and forwarding addresses cannot be used. If the two temporary random numbers are still valid, the communication node must remember the specific link between the index of the temporary random number and the address and serial number. Until a temporary random number expires.

4. Confirm sending bindingRecognize

When any node receives A packet containing the bound update message and the confirmation bit (A) in the message is set, it must send A binding confirmation message to confirm that the bound update is received. If this node accepts the Binding Update and generates or modifies a binding cache entry for the mobile node, and the confirmation bit in the binding update is set, the Status field of the binding confirmation must be set to a value smaller than 128. If the node accepts the Binding Update, but the confirmation bit in the Binding Update Is Not set, the node should not send the binding confirmation; if this node rejects the Binding Update and does not generate or modify a binding cache entry for the mobile node, even if the validation bit in the Binding Update Is Not set, the receiving node must also send the binding confirmation, and the Status field must be set to a value greater than or equal to 128.

The returned data packets for the included binding validation must meet the special authentication requirements for the binding validation. In addition, if a packet is sent to any address other than the owner address of the mobile node, the Routing Header must be used (even if the binding is rejected ).

The intermediate IP address that passes through before the packet is sent to the owner address should be determined by these factors: as long as the binding update with a non-zero survival time is accepted, it is necessary to use the forwarding address industry to construct the Routing header. Otherwise, if the source IP address containing the bound update packet can be legally included in the Routing header, the IP address is used to construct the Routing header. Note: you cannot use multicast addresses, local link addresses, loopback addresses, addresses mapped to IPv4 addresses, or unspecified addresses in the Routing headers used for binding validation. Otherwise, if the binding time in the update is 0, but the source IP address cannot be used in the Routing header, the binding confirmation must be sent to the owner address of the mobile node. When the lifetime of the bound cache entry expires, these entries must be deleted from the bound cache.

5. Send a binding update request

If a deleted entry is still being used to send data packets to a mobile node, the next data packet sent to the mobile node will be routed to the ownership link of the mobile node as usual. Although the communication with the mobile node is not interrupted, the extra overhead and latency will be increased when the VPC sends data packets to the mobile node through tunneling encapsulation.

If the sender knows that the bound cache entry is still in use, it can send a binding update request message to the mobile node, to avoid this overhead and latency caused by deletion and re-generation of bound cache entries. The method for sending a bound update request message to a mobile node is the same as that for sending a common data packet.

The communication node can re-transmit the request message within the speed limit. When the communication node receives the initial message of the attribution test, it should stop sending the Binding Update request. At this time, the mobile node has made a response and started the return path reachable process.

Conclusion

With the continuous development of mobile communication technology, the development direction of mobile networks is "full IP mobile network ". IPv6 has been identified as the foundation for building next-generation mobile networks and a standard that must be followed by 3G, making it an indispensable technology in IP multimedia services. It is widely believed that IPv6 (especially mobile IPv6) technology will surely bring a bright spring to the development of the entire communication industry.

Related Articles]

• IPv6 opportunity: IPV6's new leading space communication team joins hands with China Mobile
  

• Research and Implementation of RIP Routing Protocol in the IPv6 age
  

• IPv6 solution for 3G Mobile Communication Systems