CN101047645A - Double-stack support extension method of layer mobile IPv6 protocol - Google Patents

Abstract

A dual-stack support extension method for a hierarchical mobile IPv6 protocol, the method comprising: MN receives an RA containing the IPv6 address of the MAP and the IPv4 address of the MAP; the MN configures RCoA and LCoA; the MN binds the MAP; the MN sends an RA containing The BU with the MN's IPv4 and IPv6 HAO is bound to the HA, and the HA responds by sending the BA containing the corresponding HAO to the MN. The advantage of the present invention is that, through expansion, only one set of mobility management protocol can be run in the dual-stack network to realize the management of the mobile node, which reduces the complexity of network entity configuration and improves the performance of network management.

Description

Dual-stack Support Extension Method of Hierarchical Mobile IPv6 Protocol

technical field

The invention belongs to the technical field of dual-stack network mobile communication, and in particular relates to a dual-stack support extension method of a hierarchical mobile IPv6 protocol (HMIPv6-Hierarchical Mobile IPv6).

Background technique

At present, the mobile network protocol (MIP-Mobile Internet Protocol) is a solution that provides mobile functions on the global Internet. It has the characteristics of good scalability, strong reliability and high security, and can guarantee the -Mobile Node) can still maintain the current ongoing communication when changing the network access point. There are two types of MIP, MIPv4 and MIPv6. The MIPv6 protocol introduces mobility features on the basis of IPv6 in order to better serve mobile users. Because IPv6 is superior to IPv4 in terms of address space and security, MIPv6 has superior performance than MIPv4.

The MIPv6 protocol stipulates that when the MN moves from its home network to a foreign network, it will obtain a care-of address (CoA-Care-of Address). In order to maintain the continuity of its communication, MN needs to register its current location with its home agent (HA-Home Agent), so that HA can forward any packets sent to or sent by MN. Obviously, in this triangular routing forwarding mode, the burden on HA is increased, which may make HA become a communication bottleneck, thereby affecting the performance of the entire link. In order to reduce the possibility of this hidden danger and achieve route optimization, the MIPv6 protocol stipulates that the MN also needs to register with the corresponding corresponding peer (CN-Corresponding Node), so that the MN can directly communicate with the CN, no longer need HA forwarding. In order to ensure the security of the mutual communication, the protocol stipulates that before the MN binds with the CN, the process of return route reachability must be carried out first. Its purpose is to verify whether the MN's home address (HoA-Home Address) and CoA are reachable to the HA, and then negotiate a communication key to complete the communication.

The MIPv6 protocol allows nodes to maintain their reachability and maintain the continuity of ongoing communication between MNs and CNs when they move within the Internet network topology. For this reason, the MN needs to send a binding update (BU-Binding Update) to its HA and all CNs for registration after each move. And for the authentication of CN's binding update, even in the best case, it needs about 1.5 times the round-trip time between MN and CN. In addition, updating both HA and CN requires 1x the round-trip time. Reuse of the home key also does not reduce the round-trip time required to update the CN. Whenever a node switches, the time delay generated by this series of update operations will interrupt the ongoing communication, thus affecting the communication quality. If these additional switching delays are eliminated or reduced during switching, the performance of MIPv6 can be significantly improved and the support for delay-sensitive services can be enhanced.

The HMIPv6 protocol proposed by the Internet Engineering Task Force (IETF-Internet Engineering Task Force) adopts a hierarchical routing structure to reduce the number of signaling interactions between the MN and the HA and CN, thereby reducing the communication interruption time caused by handover. In HMIPv6, a new functional entity called MAP-Mobility Anchor Point is introduced. A MAP area contains multiple subnets, each subnet has an access router (AR-Access Router), and the number of subnets can vary according to the situation. MN configures a specific regional care-of address (RCoA-Regional CoA) by receiving RA-Router Advertisement containing MAP information, and then uses this address to register with HA and CN. In addition, the MN will also obtain a link care-of address (LCoA-On-LinkCoA) at the same time. When the MN moves within the same MAP domain, the RCoA does not change. At this time, there is no need to re-bind to the HA and CN, which reduces the interaction between the MN and the HA and CN when the MN moves between subnets within the MAP domain. frequency.

It can be seen from the above description that both the MIPv6 protocol and the HMIPv6 protocol are only applicable to IPv6 networks. However, the current actual situation is that IPv6 networks have not been widely deployed, and most of the Internet is still an IPv4 network, or a network where IPv4 and IPv6 coexist. Therefore, it is impossible for MNs to maintain their existing communications through IPv6 addresses, which limits the application of the HMIPv6 protocol. Therefore, it is necessary to expand and improve the HMIPv6 protocol to adapt to the dual-stack environment where IPv4 network and IPv6 network coexist.

Known technology 1: the MAP of HMIPv6 can be located at any layer in the hierarchical network, unlike the foreign agent in mobile IPv4, the MAP does not require an independent subnet. MAP will reduce the number of information exchange in MIPv6 local range. The introduction of MAP provides solutions to the following problems:

When the MN moves within the same MAP domain, it only needs to send a local local binding update (LBU-Local Binding Update) to the MAP, instead of sending it to the HA and the CN.

After the MN moves to a new MAP domain, the MN only needs to send a BU to the HA and the CN once, and this process has nothing to do with the number of CNs the MN is communicating with.

MAP is essentially a local HA. The purpose of introducing a hierarchical mobility management model in MIPv6 is to improve the performance of MIPv6 while minimizing the impact on MIPv6 or other IPv6 protocols.

When the MN moves to a hierarchical foreign network, it will receive an RA containing the MAP option. This option is filled with the relevant information of the MAP in this domain, including the distance, length, and address of the MAP, etc. By using this option, the MN can also determine whether it is still in the original MAP domain. If the MN moves within the same MAP domain, the RA will receive information about the same MAP. Once receiving the RA whose MAP address changes, the MN must send a BU to the HA and all CNs to make corresponding changes.

If the MN is a node that does not support HMIPv6, it will no longer execute the process of the HMIPv6 protocol, and at this time, the MN will still perform mobility management as defined in MIPv6. If the MN is a node supporting HMIPv6, it should choose to use the HMIPv6 protocol for mobility management.

Operation of MN:

When the MN moves to a new MAP domain, two care-of addresses need to be configured: one is the RCoA generated according to the MAP address prefix, and the other is the LCoA. RCoA is generated in a stateless address auto-configuration mode, and LCoA can be generated in a stateless address auto-configuration mode, or can be assigned through a Dynamic Host Configuration Protocol (DHCP-Dynamic Host Configuration Protocol).

After generating the RCoA, the MN needs to send an LBU to the MAP, which indicates that the M flag bit registered with the MAP and the A flag bit that requires binding confirmation (BA-Binding Acknowledgment) must be set. The home address option (HAO-Home Address Option) in the LBU contains the RCoA of the MN. This message does not include an alternative care-of address option. The source address of the LBU is LCoA. MAP will perform duplicate address detection (DAD-Duplicate Address Detection) for the RCoA of the MN, and return a local binding confirmation message (LBA-Local Binding Acknowledgment) to the MN. The mobile node MUST ignore BA packets that contain the mobile node's RCoA but do not contain a type 2 routing header.

After the MN successfully registers, a two-way tunnel will be established between the MN and the MAP. All packets sent by the MN will be sent to the MAP through the tunnel. The source address in the packet external header is the LCoA of the MN, and the destination address is the address of the MAP. In the internal header, the source address is the RCoA of the MN, and the destination address is the address of the CN. Similarly, all packets whose destination address is the MN's RCoA are intercepted by the MAP and forwarded to the MN's LCoA through the tunnel.

If the MN receives an RA containing multiple MAP option information, multiple RCoAs can be configured. In this case, the mobile node must perform a binding update procedure for each RCoA.

After registering with the MAP, the MN must register the new RCoA with its HA. Wherein, the HAO is the HoA of the MN, and the CoA is the RCoA. At the same time, MN also needs to send BU to its CN.

The MN should wait to register with the HA after receiving the LBA from the MAP. The lifespan bound to HA and CN cannot be greater than the lifespan bound to MAP, and the bounded lifespan is obtained in LBA.

In order to increase the switching speed between MAPs and reduce packet loss, the MN should send LBUs to its original MAP to register its new LCoA. In this way, the packets arriving at the original MAP can also be immediately forwarded to the new LCoA.

It should be noted that if the CN and the MN are on the same link, the address of the MN executing the BU can be its LCoA. In this way, the MN and the CN can communicate directly without forwarding by the MAP.

Operation of MAP:

MAP plays the role of HA: it intercepts all packets whose destination address is MN's RCoA, and forwards them to the current LCoA of MN through the tunnel.

The MAP is not aware of the MN's HoA. The MN sends an LBU containing M and A bits to the MAP. The purpose of this binding is to indicate to the MAP that the MN has formed an RCoA. If the binding is successful, the MAP must return an LBA to indicate the success of the registration. This is the same operation as HA. No new error encodings were introduced in HMIPv6. The BA must contain a Type 2 routing header, which contains the MN's RCoA.

The MAP must be able to intercept and forward packets from the MN through the tunnel. Among them, the MN is the entry point of the tunnel, and the MAP is the exit point of the tunnel.

The MAP acts as the HA of the LCoA, and all packets whose destination address is RCoA are intercepted by the MAP through proxy neighbor notification, and then encapsulated and routed to the LCoA of the MN.

As for the operation of HA and CN, HMIPv6 has not made any modification.

The disadvantage of the first known technique is that it is only applicable to IPv6 networks and does not support IPv4 nodes.

The second known technology: that is, the MIPv6 protocol supports dual-stack nodes.

The MIPv6 protocol supports some operations of IPv6 nodes. For nodes that do not support IPv6, the protocol needs to be modified to meet the requirements of dual-stack nodes such as IPv4 and IPv6. In order to enable dual-stack nodes to use the MIPv6 protocol, the MN should use both an IPv4 and an IPv6 HoA, and register these two addresses with its HA; and the MN should know the IPv4 and IPv6 addresses of the HA, but not for the IPv4 address Perform prefix discovery. In order to enable a dual-stack node to use the MIPv6 protocol for mobility management, it is necessary to modify its home BU and corresponding BA information. The specific instructions are as follows:

When a dual-stack MN moves to a foreign network, it needs to register with its HA and bind its current CoA. In order for the MN to maintain communication in a foreign network that does not support IPv6, the MN needs an IPv4 HoA and establishes a corresponding binding cache entry for each address. At this time, the format of the IP data packet carrying BU and BA will be different. It depends on whether the foreign network supports IPv6. There will be three different situations:

The foreign network supports IPv6, and an IPv6 CoA is configured for the MN;

The MN configures only one globally unique IPv4 address in the foreign network;

The MN configures a private IPv4 address on the foreign network.

The following three situations are analyzed separately:

The foreign network supports IPv6:

At this time, the MN can configure a globally unique IPv6 address. MN will send BU to the IPv6 address of HA. The BU may contain IPv4 HAO. After receiving a BU, HA will create two binding cache entries. One is used to store the MN's IPv4 HoA, and the other is used to store the MN's IPv6 HoA. Both cache entries point to the MN's IPv6 CoA. Therefore, packets whose destination address is the MN's IPv4 or IPv6 HoA can be sent to the MN's IPv6 CoA through the tunnel. In order to improve efficiency, the MN can establish two different tunnels, one for IPv4 services and the other for IPv6 services.

In this case, it is only necessary to add an IPv4 HAO in the BU.

After receiving a BU and completing the corresponding binding cache entry, the HA must send a BA to the MN. In addition, if the HAO of IPv4 is included in the BU, this item must also be included in the BA. Indicates acceptance of the MN's IPv4 HoA.

When the MN obtains both IPv4 and IPv6 CoA in the foreign network, it will preferentially use the IPv6 CoA for MIPv6 binding registration.

For foreign networks that only support IPv4, there will be the following two situations:

Foreign networks only support IPv4 public addresses:

At this time, the MN needs to send the IPv6 packet containing the BU to the IPv4 address of the HA through the tunnel. The source address of the external header is the IPv4 CoA obtained by the MN from the foreign network, and the HAO in the BU includes the MN's IPv6 HoA. However, since the CoA is the MN's IPv4 address, the MN must include the IPv4's CoA in the IPv6 packet.

After receiving the BU, the HA must create a binding cache entry for the MN's IPv6 HoA. If the HAO of IPv4 is included in the BU, another cache entry must be created for this address, and all entries point to the CoA of IPv4 of the MN. Therefore, all packets whose destination address is the HoA of the MN will be encapsulated in an IPv4 header. Wherein, the source address is the HoA of IPv4 of the HA, and the destination address is the CoA of IPv4 of the MN.

The foreign network only supports IPv4 private addresses:

At this time, the MN needs to send the IPv6 packet containing the BU to the IPv4 address of the HA through the tunnel. In order to pass through the Network Address Translation (NAT-Network Address Translation), IPv6 packets are encapsulated in IPv4 packets in the form of User Datagram Protocol (UDP-User Datagram Protocol) to be forwarded through the tunnel. In the IPv4 header, the MN uses the IPv4 address obtained from the foreign network as the source address, and the MN's IPv6 HoA contained in the HAO of the BU. The content of the IPv6 packet is the same as that of the public address.

After receiving the BU, the HA must create a binding cache entry for the MN's IPv6 HoA. If it contains IPv4 HAO, it must be created separately. All items must point to the MN's IPv4 CoA in the IPv6 packet source address domain. Therefore, the packets whose destination address is the MN's HoA are all encapsulated with UDP, and then encapsulated in an IPv4 header. The source address in the header is the IPv4 address of the HA, and the destination address is the CoA of the MN's IPv4.

In the dual-stack situation, the route optimization method between MN and CN is no longer applicable, and all packets will be forwarded through HA.

The defect of the second known technology is that the solution runs the MIPv6 protocol, so it has all the shortcomings of the MIPv6 protocol, and is especially unsuitable for delay-sensitive services.

Contents of the invention

The main purpose of the present invention is to solve the above-mentioned defects, avoid the existence of defects, and provide a dual-stack support extension method of the hierarchical mobile IPv6 protocol. When the MN moves to a foreign network, the method includes:

The MN receives the RA containing the IPv6 address of the MAP;

MN configures RCoA and LCoA;

MN binds with MAP;

The MN binds with the HA, and the MN includes a HAO in the BU sent to the HA to store the MN's IPv6 HoA, and the HA responds by sending a BA containing the corresponding HAO to the MN.

A dual-stack support extension method for hierarchical mobile IPv6 protocol further includes: the MN receives the RA containing the IPv4 address of the MAP in the external area.

A dual-stack support extension method of the hierarchical mobile IPv6 protocol. During the binding process between the MN and the HA, the BU sent to the HA also includes a HAO to store the MN's IPv4 HoA.

A dual-stack support extension method of the hierarchical mobile IPv6 protocol, the RCoA configured by the MN is generated in a stateless address auto-configuration mode according to the MAP address prefix.

Compared with the known technology, the present invention has the advantages that in a dual-stack network, two sets of mobility management protocols are run separately, which not only increases the complexity of each node configuration, but also increases the complexity of network management. Once a node moves, a large amount of information interaction will occur, which will have a great impact on the performance of the entire network. The invention can realize the management of the mobile node by running only one set of mobility management protocols in the double-stack network through expansion, reduces the complexity of network entity configuration, and improves the performance of network management.

Description of drawings

Figure 1 is a basic topology diagram of the hierarchical mobile IPv6 protocol;

FIG. 2 is a diagram of an information interaction process of a dual-stack network.

Detailed ways

Relevant technical content and detailed description of the present invention, now cooperate accompanying drawing to explain as follows:

In order to enable the HMIPv6 protocol to support dual-stack network nodes, the present invention proposes a dual-stack support extension method of the HMIPv6 protocol, which is used to support IPv4 and IPv6 services. In HMIPv6, all groups between MN and CN are forwarded by HA and MAP. When the CN sends a packet to the MN, it is firstly intercepted by the HA and forwarded to the MAP in the domain where the MN is currently located, and then sent to the MN by the MAP.

In a dual-stack network, that is, all nodes in the network support IPv4 and IPv6, the present invention needs to modify the RA, increase the IPv4 address announcement of the MAP in the external area, and also need to add a home address option HAO in the BU sent to the HA to store The MN's IPv4 HoA ensures the continuity of dual-stack node communication. When the MN leaves home and moves to a foreign network, the required CoA is configured according to the support of the foreign network for IPv6. Since the mobility management protocol running in the network is the HMIPv6 protocol, there must be a MAP supporting IPv6, and the present invention assumes that all MAPs support IPv6. And the MAP also has an IPv4 address and an IPv6 address at the same time.

Figure 1 is a basic topology diagram of the hierarchical mobile IPv6 protocol. When the foreign network supports IPv6, the operation process of the whole HMIPv6 protocol is exactly the same as the normal situation, and the current RCoA and LCoA are both IPv6. It is only necessary to add a HAO about the MN's IPv4 in the binding update from the MN to the HA to generate IPv4 binding cache entries on the HA and the MAP to ensure that the MN can communicate with IPv4 nodes. When the foreign network does not support IPv6, there will be three situations that need to be discussed separately. The following describes the situation of the foreign network where the MN is located. FIG. 2 is a diagram of an information interaction process of a dual-stack network.

1. The foreign network supports IPv6:

Both AR1 and AR2 under the MAP in the present invention support IPv6. When the MN moves to such a foreign network, it receives an RA containing the address of the MAP. In this announcement, it contains both the IPv6 address of the MAP, the IPv4 address of the MAP, and the care-of address. Here, IPv6 addresses will be used first.

According to the HMIPv6 protocol, the MN can configure RCoA and LCoA. Since the current AR also supports IPv6, these two addresses are IPv6 addresses. After the address configuration is successfully completed, the MN needs to send an LBU to the MAP. The source address of the information is the LCoA, and the destination address is the IPv6 address of the MAP. The RCoA of the MN is filled in the HAO. The status of LCoA in the MAP domain in HMIPv6 is the same as that of CoA in the HA domain in MIPv6. It needs to be used to establish binding cache entries. The HAO should be filled with the HoA of the MN, and the corresponding one in HMIPv6 is RCoA. In MIPv6, the address used by the MN to communicate with the CN is the HoA of the MN, but the source address used in the network routing process of the packet is the CoA of the MN. At this time, the HoA of the MN should be filled in the HAO, and the CN will submit it to the HAO after receiving it. When the upper-layer application program, the upper-layer application program can know whether it is a packet sent by the MN communicating with the program through the HAO. The format of the LBU at this time is exactly the same as that stipulated in HMIPv6.

After receiving the LBU of the MN, the MAP sends out corresponding LBA information, the source address of which is the IPv6 address of the MAP, and the destination address is the LCoA of the MN. The HoA confirmation option is filled with the RCoA of the MN.

After that, MN sends BU to HA. The source address of the information is the RCoA of the MN, and the destination address is the IPv6 address of the HA. The IPv6 address of the HA refers to the address that is consistent with the prefix of the HoA of the MN, so that the packets sent by the MN to the HA can be routed normally. network, that is, all packets sent to the MN must reach the MN through this interface of the HA, and vice versa. Here, as MIPv6 supports dual-stack nodes, in this BU, an HAO is added to store the MN's IPv4 HoA. Therefore, the two HAOs in the BU are filled with the MN's IPv4 and IPv6 HoA respectively. In this way, the HA needs to establish two binding cache items for the MN, one for storing the IPv6 HoA and the other for storing the IPv4 HoA, but both of them point to the RCoA of the MN. The HoA of IPv4 is the HoA of IPv4 of the MN. The address is a unicast IPv4 address, which may be public or private. In the present invention, the address is a public IPv4 address. For private addresses, only need to go through NAT.

Before the MN has moved to other networks, the HA and the MN communicate directly without forwarding. When the MN moves to a foreign network, the packets sent by the CN to the MN must still be sent to the HA, because the CN does not know whether the MN Move, but after the MN moves, through the above process of sending BU and receiving BA, a binding cache entry is established in the HA, which specifies the current address CoA of the MN and the corresponding HoA, so that after the HA receives the packet sent by the CN to the MN, if If the entry exists, the current address of the destination MN of the packet will be found according to the mapping relationship between the HoA and the CoA of the entry, and the packet will be forwarded to the MN.

When the HA receives the BU of the MN, it sends out a corresponding BA message, the source address of which is the IPv6 address of the HA, and the destination address is the RCoA of the MN. In this BA, the two HoA confirmation options of the response are filled with the MN's IPv4 and IPv6 HoA respectively. Wherein, the HoA of IPv4 is the HoA of IPv4 to be used by the HA in the binding cache. The address is a unicast IPv4 address, which may be public or private. In the present invention, the address is a public IPv4 address. For private addresses, only need to go through NAT. If the address is automatically assigned by DHCP, the HA notifies the MN of this address. Otherwise, if the address is statically configured for the MN, the HA will copy the address from the BU information.

At this time, when a dual-stack CN communicates with the MN, the packet will first be intercepted by the HA, then forwarded to the MAP in the domain where the MN is located, and finally forwarded by the MAP to the current location of the MN, where the IPv4 traffic is encapsulated In the IPv6 tunnel, the communication continuity of the MN in the dual-stack network is guaranteed.

2. The foreign network does not support IPv6

When the AR only supports IPv4, the LCoA configured by the MN is an IPv4 address. At this time, the MN first needs to send an LBU to the MAP to register its IPv4 LCoA. After receiving the LBA of the MAP, the MN will send a BU to the HA to register its RCoA. At this time, it must also include a HAO carrying the MN's IPv6. This can ensure that IPv4 and IPv6 services are forwarded at the same time.

For foreign networks that do not support IPv6, there are the following three situations when mobile triggers handover:

When the MN moves to a foreign network, it receives an RA containing the address of the MAP. In this announcement, it contains both the IPv6 address of the MAP, the IPv4 address of the MAP, and the care-of address.

(1) AR1 supports IPv6, while AR2 supports IPv4;

This situation means that the MN moves from an IPv6-supporting AR1 to an IPv4-only AR2. Since the movement within the MAP domain occurs, the RCoA of the MN does not change, but only the LCoA changes. At this time, since the current AR2 is an IPv4 node, the LCoA generated by the configuration is an IPv4 address. The MN needs to send the LBU to the MAP, the source address in the IPv4 header of the information is the LCoA of the MN, and the destination address is the IPv4 address of the MAP. The source address in the inner IPv6 header is the RCoA of the MN, and the destination address is the IPv6 address of the MAP. Since AR2 only supports IPv4, the MN can only use IPv4 LCoA, and the previous IPv6 LCoA can no longer be used, so it can only encapsulate IPv6 RCoA in the inner layer header, because RCoA is needed to establish binding cache entries, so that MAP Intercept the IPv6 RCoA packet sent to the MN and encapsulate it into an IPv4 packet and send it to the MN. The HAO is filled with the RCoA of the MN. The format of the LBU at this time is exactly the same as that stipulated in HMIPv6.

After receiving the LBU of the MN, the MAP sends out the corresponding LBA information, the source address in the IPv4 header of the information is the IPv4 address of the MAP, and the destination address is the LCoA of the MN's IPv4. The source address in the IPv6 header is the IPv6 address of the MAP, and the destination address is the RCoA of the MN's IPv6. The HoA confirmation option is filled with the RCoA of the MN.

At this time, because the MN moves within the MAP domain, according to the HMIPv6 protocol, the MN does not need to send binding to the HA. The MAP intercepts all packets sent by the HA to the RCoA of the MN, and then encapsulates the IPv6 traffic in the IPv4 tunnel to the LCoA of the MN's IPv4.

(2) AR1 supports IPv4, and AR2 also supports IPv4;

When the MN moves between such two ARs, the LCoA changes, and the binding process between the MN and the MAP is the same as (1).

(3) AR1 supports IPv4, while AR2 supports IPv6.

This situation means that the MN moves from an IPv4-supporting AR1 to an IPv6-only AR2. Since the movement within the MAP domain occurs, the RCoA of the MN does not change, but only the LCoA changes. At this time, since the current AR2 is an IPv6 node, the LCoA generated by the configuration is an IPv6 address. The MN needs to send the LBU to the MAP, the source address in the IPv6 header of the information is the LCoA of the MN, and the destination address is the IPv6 address of the MAP. The HAO is filled with the RCoA of the MN. The format of the LBU at this time is exactly the same as that stipulated in HMIPv6.

After receiving the LBU of the MN, the MAP sends out the corresponding LBA information, the source address in the IPv4 header of the information is the IPv4 address of the MAP, and the destination address is the LCoA of the MN. The source address in the IPv6 header is the IPv6 address of the MAP, and the destination address is the LCoA of the MN. The HAO is filled with the RCoA of the MN.

At this time, because the MN moves within the MAP domain, according to the HMIPv6 protocol, the MN does not need to send binding to the HA. Other packet transmissions are similar to those of IPv6.

The substantive difference between (1) and (3) is that the protocol of the source address and destination address in the packet header of the LBU sent out is different: the former is IPv4, and the latter is IPv6. The root cause is whether IPv6 is supported, and switching After completion, the established tunnel types from the MAP to the MN are also different, the former is IPv4-in-IPv4, and the latter is IPv6-in-IPv6. But in either case, the RCoA of the MN's IPv6 is registered on the HA, and the former RCoA on the MAP points to the MN's IPv4 LCoA, and the latter points to the IPv6 LCoA.

When the MN is located in a network that only supports IPv4, it will send IPv6 packets encapsulated in the IPv4 tunnel to the HA in the following format: In the outer IPv4 header, the source address is the LCoA of the MN's IPv4, and the destination address is the IPv4 address of the HA . In the inner IPv6 header, the source address is the MN's IPv6 HoA, and the destination address is the CN's IPv6 address. Similarly, the MN will send an IPv4 tunnel packet to the HA in the following format: In the outer IPv4 header, the source address is the MN's IPv4 LCoA, and the destination address is the HA's IPv4 address. In the inner IPv4 header, the source address is the MN's IPv4 HoA, and the destination address is the CN's IPv4 address.

The present invention is mainly implemented from the perspective of IPv6 by modifying the HMIPv6 protocol. In fact, support for dual-stack nodes can also be realized by modifying the MIPv4 protocol and MIPv4 area registration.

The foregoing are only preferred embodiments of the present invention, and are not intended to limit the implementation scope of the present invention. That is, all equivalent changes and modifications made according to the patent scope of the present invention are covered by the patent scope of the present invention.

Claims (4)

1, a kind of double-stack support extension method of layer mobile IPv 6 protocol when MN moves to field network, is characterized in that, comprises:

MN receives the RA of the IPv6 address that includes MAP;

MN configuration RCoA and LCoA;

MN and MAP bind;

MN and HA bind, and MN comprises the HoA that a HAO deposits the IPv6 of MN in mailing to the BU of HA, the HA response, and the BA that sends the HAO that includes correspondence is to MN.

2, method according to claim 1 is characterized in that, further comprises: MN receives the RA of the IPv4 address that includes MAP in the external region.

3, method according to claim 1 and 2 is characterized in that: in the process that MN and HA bind, also comprise the HoA that a HAO deposits the IPv4 of MN in mailing to the BU of HA.

4, method according to claim 3 is characterized in that: the RCoA of MN configuration generates with the stateless address auto configuration mode according to the MAP address prefix.

Images