In this case, an optional feature called reverse tunneling may be deployed, if it is supported by the mobile node, the home agent and if relevant, the foreign agent. When this is done, a reverse tunnel to complement the normal one is set up between the mobile node and the home agent, or between the foreign agent and the home agent, depending on care-of address type. Thus, it is used only when necessary. One situation where reverse tunneling may be required is if the network where the mobile node is located has implemented certain security measures that prohibit the node from sending datagrams using its normal IP address.
Key Concept: An optional feature called reverse tunneling may be used in certain cases, such as when a network does not allow outgoing datagrams with a foreign source IP address. When enabled, rather than sending datagrams directly, the mobile node tunnels all transmissions back to the home agent, which sends them on the Internet. Broadcast datagrams on the home network, which would normally be intended for the mobile node if it were at home, are not forwarded unless the node specifically asks for this service during registration.
Multicast operation on the foreign network is also supported, but extra work is required by the mobile node to set it up. Please Whitelist This Site? Thanks for your understanding! NOTE: Using software to mass-download the site degrades the server and is prohibited.
Thank you. The Book is Here Note that the broadcast is not an Internet-wide broadcast, but a directed broadcast that reaches only IP nodes on the home network. The new tunnel header uses the mobile node's care-of address as the destination IP address, or tunnel destination.
The tunnel source IP address is the home agent, and the tunnel header uses 4 as the higher level protocol number, indicating that the next protocol header is again an IP header. Therefore, to recover the original packet, the foreign agent merely has to eliminate the tunnel header and deliver the rest to the mobile node. Figure 2 shows that sometimes the tunnel header uses protocol number 55 as the inner header. This happens when the home agent uses minimal encapsulation 11 instead of IP-within-IP. Processing for the minimal encapsulation header is slightly more complicated than that for IP-within-IP, because some of the information from the tunnel header is combined with the information in the inner minimal encapsulation header to reconstitute the original IP header.
On the other hand, header overhead is reduced. It retains the ideas of a home network, home agent, and the use of encapsulation to deliver packets from the home network to the mobile node's current point of attachment. While discovery of a care-of address is still required, a mobile node can configure its a care-of address by using Stateless Address Autoconfiguration and Neighbor Discovery.
Thus, foreign agents are not required to support mobility in IPv6. IPv6-within-IPv6 tunneling is also already specified. Route Optimization IPv6 mobility borrows heavily from the route optimization ideas specified for IPv4, 20 particularly the idea of delivering binding updates directly to correspondent nodes. When it knows the mobile node's current care-of address, a correspondent node can deliver packets directly to the mobile node's home address without any assistance from the home agent. Route optimization is likely to dramatically improve performance for IPv6 mobile nodes.
It is realistic to require this extra functionality of all IPv6 nodes for two reasons. First, on a practical level, IPv6 standards documents are still at an early stage of standardization, so it is possible to place additional requirements on IPv6 nodes. Second, processing binding updates can be implemented as a fairly simple modification to IPv6's use of the destination cache.
Security One of the biggest differences between IPv6 and IPv4 is that all IPv6 nodes are expected to implement strong authentication and encryption features 21 , 22 to improve Internet security. This affords a major simplification for IPv6 mobility support, since all authentication procedures can be assumed to exist when needed and do not have to be specified in the Mobile IPv6 protocol.
Even with the security features in IPv6, however, the current working group draft for IPv6 mobility support specifies the use of authentication procedures as infrequently as possible.
The reasons for this are twofold. First, good authentication comes at the cost of performance and so should be required only occasionally. Second, questions about the availability of Internet-wide key management are far from resolved at this time. Source Routing In contrast to the way in which route optimization is specified in IPv4, in IPv6 correspondent nodes do not tunnel packets to mobile nodes.
Instead, they use IPv6 routing headers, which implement a variation of IPv4's source routing option. A number of early proposals for supporting mobility in IPv4 specified a similar use of source routing options, 23 , 24 but two main problems precluded their use:. However, the objections to the use of source routes do not apply to IPv6, because IPv6's more careful specification eliminates the need for source-route reversal and lets routers ignore options that do not need their attention. Consequently, correspondent nodes can use routing headers without penalty.
Tunneling protocol - Wikipedia
This allows the mobile node to easily determine when a correspondent node does not have the right care-of address. Packets delivered by encapsulation instead of by source routes in a routing header must have been sent by correspondent nodes that need to receive binding updates from the mobile node. It is a further point of contrast to route optimization in IPv4 that, in IPv6 mobility support, the mobile node delivers binding updates to correspondent nodes instead of to the home agent.
In IPv6, key management between the mobile node and correspondent node is more likely to be available. Problems Facing Mobile IP The most pressing outstanding problem facing Mobile IP is that of security, but other technical as well as practical obstacles to deployment exist. This section surveys the state of implementation of Mobile IP and speculates on a possible timetable for deployment.
- Reverse Tunneling for Mobile IP, revised.
- Your Answer.
- free people search for death records.
- Reverse Tunneling on Mobile IP.
- Mobility Support.
Routing inefficiencies. The base Mobile IP specification has the effect of introducing a tunnel into the routing path followed by packets sent by the correspondent node to the mobile node.
Packets from the mobile node, on the other hand, can go directly to the correspondent node with no tunneling required. This asymmetry is captured by the term triangle routing, where a single leg of the triangle goes from the mobile node to the correspondent node, and the home agent forms the third vertex controlling the path taken by data from the correspondent node to the mobile node. Triangle routing is alleviated by use of techniques in the route optimization draft, 20 but doing so requires changes in the correspondent nodes that will take a long time to deploy for IPv4. It is hoped that triangle routing will not be a factor for IPv6 mobility.
Security issues. A great deal of attention is being focused on making Mobile IP coexist with the security features coming into use within the Internet. Firewalls, 27 in particular, cause difficulty for Mobile IP because they block all classes of incoming packets that do not meet specified criteria. Enterprise firewalls are typically configured to block packets from entering via the Internet that appear to emanate from internal computers.
Although this permits management of internal Internet nodes without great attention to security, it presents difficulties for mobile nodes wishing to communicate with other nodes within their home enterprise networks. Such communications, originating from the mobile node, carry the mobile node's home address, and would thus be blocked by the firewall.
Mobile IP can be viewed as a protocol for establishing secure tunnels. Gupta and Glass have proposed a firewall traversal solution. Ingress filtering.
Complications are also presented by ingress filtering 25 operations. Many border routers discard packets coming from within the enterprise if the packets do not contain a source IP address configured for one of the enterprise's internal networks. Because mobile nodes would otherwise use their home address as the source IP address of the packets they transmit, this presents difficulty. Solutions to this problem in Mobile IPv4 typically involve tunneling outgoing packets from the care-of address, but then the difficulty is how to find a suitable target for the tunneled packet from the mobile node.
The only universally agreed on possibility is the home agent, but that target introduces yet another serious routing anomaly for communications between the mobile node and the rest of the Internet. Montenegro has proposed the use of reverse tunnels to the home agent to counter the restriction imposed by ingress filtering. User perceptions of reliability. However, opinion is not unanimous on the need for this feature.
Many people believe that computer communications to laptop computers are sufficiently bursty that there is no need to increase the reliability of the connections supporting the communications. The analogy is made to fetching Web pages by selecting the appropriate URLs. If a transfer fails, people are used to trying again. This is tantamount to making the user responsible for the retransmission protocol and depends for its acceptability on a widespread perception that computers and the Internet cannot be trusted to do things right the first time.
Naturally, such assumptions are strongly distasteful to many Internet protocol engineers, myself included. Nevertheless, the fact that products exhibiting this model are currently economically viable cannot be denied.
Hopefully in the near future better engineering will counter this perception and increase the demand for Internet reliability. Issues in IP addressing. Mobile IP creates the perception that the mobile node is always attached to its home network. This forms the basis for the reachability of the mobile node at an IP address that can be conventionally associated with its fully qualified domain name FQDN. Moreover, it is possible that such an alternative IP address would offer a shorter routing path if, for instance, the address were apparently located on a physical link nearer to the mobile node's care-of address, or if the alternative address were the care-of address itself.
Finally, many communications are short-lived and depend on neither the actual identity of the mobile node nor its FQDN, and thus do not take advantage of the simplicity afforded by use of the mobile node's home address. These issues surrounding the mobile node's selection of an appropriate long-term or not-so-long-term address for use in establishing connections are complex and are far from being resolved. Slow growth in the wireless LAN market.
Mobile IP has been engineered as a solution for wireless LAN location management and communications, but the wireless LAN market has been slow to develop. It is difficult to make general statements about the reasons for this slow development, but with the recent ratification of the IEEE Moreover, the bandwidth for wireless devices has been constantly improving, so that radio and infrared devices on the market today offer multimegabyte-per-second data rates. Faster wireless access over standardized MAC layers could be a major catalyst for growth of this market.
Competition from other protocols. Although I believe portable operation will ultimately not be a long-term solution, it may look quite attractive in the short term in the absence of full Mobile IP deployment. If these alternative methods are made widely available, it is unclear if the use of Mobile IP will be displaced or instead made more immediately desirable as people experience the convenience of mobile computing. In the future, it is also possible that Mobile IP could specify use of such alternative tunneling protocols to capitalize on their deployment on platforms that do not support IP-within-IP encapsulation.
Current Development Efforts Mobile IP has been studied in a number of wireless communication research projects. At the University of California at Berkeley, 35 Mobile IP is being used to construct vertical handoffs between dissimilar media for example, infrared, radio LANs, wide-area cellular, and satellite , depending upon error rates and bandwidth availability.
Other factors such as cost and predictive service might also be taken into account. Two books about Mobile IP have recently been published. This may help cut the number of registrations that must transit the global Internet between the home and foreign networks. As this brief introduction to mobile networking has shown, Mobile IP has great potential.