CURRENT_MEETING_REPORT_ Reported by David Johnson/Carnegie Mellon University Minutes of the IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP) The minutes were prepared by Dave Johnson and edited for clarity by the co-chairs. Introduction The Mobile IP Working Group met twice during the week, once on Tuesday afternoon and again on Wednesday afternoon. Tuesday's meeting was devoted to the discussion of a number of issues in detail, and Wednesday's meeting was devoted to a line-by-line review of Version 9 of the base protocol draft and a short presentation on the Route Optimization extensions. Patent Issues IBM holds a patent covering work done by Charlie Perkins on mobile IP. In San Jose, the group decided to send a letter to IBM requesting a no-cost license for use of this technology in the Mobile IP protocol, but Tony Li announced that he had not been able to get this letter out until last week. A reply has not yet been received from IBM, but Charlie Perkins and John Tavs (IBM Raleigh) told the group unofficially that IBM's lawyers are working on it. IBM also holds a patent related to the use of nonces for replay protection, and we are likewise pursuing a no-cost license from IBM to use this technology in Mobile IP. If you are interested in becoming a ``test case'' for the IBM patent licensing, contact John Tavs. Implementations and Interoperability Testing Surprise was expressed that there does not seem to be much in the way of implementation progress on the protocol to date, although IBM has completed an implementation, and several additional implementations are in progress. It seems we have been busy with other things, such as getting the protocol definition worked out. Charlie Perkins is coordinating implementation interoperability testing, and the mailing list will be used to discuss implementation issues and progress. A small group of implementors met briefly after the Tuesday working group meeting, and it was suggested that the group would probably hold an interim meeting for interoperability testing sometime late this summer. Broadcast and Multicast Support Some applications that people may want to run require the ability to send broadcast or multicast datagrams to mobile nodes away from home, and the ability for mobile nodes away from home to send broadcast or multicast datagrams. The example of running NetBIOS was briefly discussed. For broadcast support, it was decided to add two new flag bits to the Registration Request message: one bit to request the home agent to forward all broadcast IP datagrams from the home network to the mobile node, and a second bit to indicate that the mobile node is registering with its own dynamically-assigned care-of address rather than with a care-of address associated with a foreign agent. To encode these bits in the Registration Request, it was decided to change the existing Code field to be a byte of flags. One bit was essentially already used in this byte to indicate to the home agent to remove all previous simultaneous bindings for the mobile node. Two more of these bits were used for the two new bits to support broadcast datagram forwarding, and since there are now some spare bits, one more was used to replace the existing extension to indicate availability of support for the minimal encapsulation protocol. When needed, there are still four more spare bits in this byte. When requested by the mobile node (with the first of the two new bits in the Registration Request), the home agent forwards all received broadcast IP datagrams to the mobile node. The method used to forward each depends on whether the mobile node is using its own dynamically-assigned care-of address or is registered using a care-of address associated with a foreign agent (indicated by the second of the two new bits when the mobile node registered). When using a dynamically-assigned care-of address, the home agent simply tunnels each received broadcast IP datagram to this care-of address. When registered through a foreign agent, an extra level of encapsulation is required to indicate to the foreign agent which mobile node to deliver the tunneled datagram to when it is received by the foreign agent. The home agent first encapsulated the broadcast datagram in a unicast datagram addressed to the mobile node's home address, and then tunnels this encapsulated datagram to the foreign agent. When received by the foreign agent, the unicast encapsulated datagram is detunneled and delivered to the mobile node in the same way as any other datagram. The mobile node must decapsulate this datagram to receive the original broadcast datagram. The extra level of encapsulation is necessary, since otherwise, the mobile node's home address would not appear anywhere in the tunneled datagram received by the foreign agent. Similar extra encapsulation is not required when using a dynamically-assigned care-of address, since the tunnel then terminates with the mobile node rather than with a foreign agent. For multicast support, it was decided that no changes to the Mobile IP protocol are required. There will be an informational appendix in the draft, though, describing how multicast would work. Tony Li and Charlie Perkins will craft the text for this appendix. In a small digression on this subject, it was realized that the care-of address for a mobile node must be a unicast address, and decided the home agent should reject any registration attempt that gives a broadcast or multicast address as the care-of address. Change In Use Of MD5 Following the recommendation of the IP Security Working Group, we agreed to change the way in which we use MD5 to authenticate Mobile IP messages. Instead of MD5(key || message || key) we will now use MD5(key || MD5(message)) (1) (1) Charlie Perkins and Jim Solomon attended the IPSEC session on Thursday morning at which it was determined that there are problems with this suggested change. Therefore, Charlie and Jim agreed that the Mobile IP draft should remain unchanged until IPSEC itself comes to consensus on the proper way to use MD5 to compute an authenticator. -- Jim Solomon Preferences In Agent Advertisements The question was raised about whether we really needed or should be using the router preferences in Agent Advertisements as mobility agent preferences. This is overloading their meaning, since they are already used to giving the preferences for nodes choosing a first-hop router, and the preferences for choosing a mobility agent may be different. The current version of the Mobile IP draft also left several unanswered questions about particular values to use for the preference, such as requiring that a home agent that does not also provide foreign agent services use a preference less than the highest foreign agent preference, but it had not specified what the cutoff preference should be. It was decided, instead, that the existing ``F'' (foreign agent), ``H'' (home agent), and ``B'' (foreign agent busy) bits in the Agent Advertisement were sufficient, and that all wording about preferences should be removed from the Mobile IP draft. Knowing The Home Agent Address The current Mobile IP draft requires a mobile node to be configured specifically with its own home agent's IP address. The group has had much discussion in past meetings about how this was inconvenient if, for example, the node serving as home agent had to be changed while the mobile node was away from home. It was decided to relax the wording in the draft to allow other alternatives. For example, one alternative is for the mobile node to use a directed broadcast to send the Registration Request to the home network, and for a home agent that receives a Registration Request sent to a broadcast address to reject the Request, including its real IP address in the rejection Registration Reply message. To support this, it was decided to add a Home Agent Address field to the data in the Registration Reply, so that this address is available to the mobile node after the foreign agent forwards the Registration Reply to the mobile node. Another alternative method for sending the Registration Request to the home agent without specifically knowing the home agent's IP address would be to use some configured address to address a ``virtual home agent''; at all times, some node in the home network would respond to this IP address in addition to its own real IP address, but which node this is could be changed by the home network administrator without reconfiguring the mobile nodes belonging to this home network. Each home network using this alternative could choose its own address to serve as the virtual home agent address, so no reserved address is required. Addresses In Registration Request and Reply Messages There was some question and confusion about what addresses are used as the source and destination address for Registration Request and Registration Reply messages. After some discussion, the group decided on the following. For registering without a foreign agent, the source address on the registration request should be the temporary address that has been acquired by the mobile node for its care-of address, and the destination address should be the address that the mobile node uses for its home agent. For the Registration Reply, the source address should be copied from the destination of the Registration Request, and the destination should be copied from the source address of the Registration Request. For registering with a foreign agent, the Registration Request from the mobile node to the foreign agent should have a source address of the mobile node's home address and a destination address of the foreign agent, copied from the source address of the Agent Advertisement in which the mobile node learned of that foreign agent. The foreign agent then sends the Registration Request on to the home agent, with a source address of the ``non-mobile side'' of the foreign agent, and a destination address of the home agent, copied from the Home Agent field of the Registration Request. The Registration Reply sent by the home agent back to the foreign agent should be sent with a source address copied from the destination address of the Registration Request to which it is replying, and a source address copied from the destination address of this Registration Request. Finally, when the foreign agent sends the Registration Reply on to the mobile node, the source address should be copied from the destination address of the original Registration Request from the mobile node, and the destination address should be the mobile node's home address. Route Optimization Dave Johnson made a short presentation on the operation of the proposed Mobile IP extensions for Route Optimization. In the base Mobile IP protocol, all datagrams for a mobile node always must go through that mobile node's home agent, adding overhead to the Internet and adding latency in eventually delivering each datagram to the mobile node. Route Optimization allows a correspondent to learn and cache the care-of address of a mobile node, and to then use this binding in tunneling its own datagrams directly there. The current draft for Route Optimization is draft-ietf-mobileip-optim-01.txt, by Dave Johnson, Charlie Perkins, and Andrew Myles. Comments on the draft should be sent to the Mobile IP mailing list. The Next Step Finally, the group discussed what the next step at this point should be. After the line-by-line review of the base draft, it appears we are very close to closure on the base draft, except that the patent issues described above have not yet been resolved. Charlie hopes to have an updated (and final, at least for implementation purposes) draft out by the end of the month. The group considered whether to wait for the resolution of the patent issues before going to Proposed Standard status, or to remove from the protocol all features and technology related to the patents and to go to Proposed Standard right away. The group decided for now to wait, while completing the base draft, continuing work on the Route Optimization extensions, and gaining implementation and interoperability experience.