CURRENT_MEETING_REPORT_ Reported by Charlie Perkins/IBM Corporation Minutes of the IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP) The Mobile IP Working Group met twice during the San Jose IETF, on Thursday, 8 December. The major focus of these meetings was to discuss the remaining open issues in the current base protocol. Discussion The group agreed to move the home address out of the ``Home Address Extension'' and into the registration request message. In a subsequent discussion on support for mobile routers, the group agreed that the prefix size is no longer needed in the ``Home Address Extension,'' therefore the entire Home Address Extension was then viewed as unnecessary, and is to be removed from the specification. The group agreed to call the ``Tony'' bit the `R' bit. After more discussion, the group decided to allocate four bits in the Mobility Extension flag field instead of three (as was decided in Toronto). So, now there will be the `R', `B', `F', and `H' bit -- the ``Registration Required,'' ``Busy,'' ``Foreign Agent,'' and ``Home Agent'' bits. It was decided to include a Foreign Agent lifetime in the Mobility Extension of the agent advertisement. The rationale was that this was required since there is no longer any predefined relationship between the service advertisement lifetime and the registration lifetime. There is already a status code (21) defined for exceeding the foreign agent lifetime. It was decided, based on the information that IBM has given permission of use of certain related patented technology, that the specification would assume the use of nonces (as the default) for replay protection purposes. The editor noted that he was not absolutely certain that the patent issue had been resolved favorably. Jim Solomon proposed to reincorporate MN$FA and FA$HA authentication extensions into the draft specification. This proposal was approved. The group decided to make the Authentication computation include the body of the UDP data as well as the extensions. The editor was directed to make a reasonable decision regarding whether the authenticator was to be computed as 0, or just not included at all in the computation. There was a request to make it clear that the default mode of use of MD5 was prefix jj data jj suffix. It was decided to specify that the Foreign Agent must avoid routing loops, and that it should drop the packets. This is logically the same as the language in the current draft, but by reversing the ordering of the clauses it is hoped that the correct emphasis will be imparted to the implementors. There was a great deal of discussion about allowing the mobile nodes to register without having any particular address available for their home agent or agents. Several schemes were put forth in the morning session. It was originally decided to table the matter for the mailing list, but since the group ended up having a lot of extra time in the afternoon, the issue was taken up then; some interesting results were obtained which will be described later. After not too much discussion, the group generally agreed to adopt the proposal (by Tony Li and Andrew Myles) put forth on the mailing list regarding mobile routers. The working group requested that language be inserted into the draft clarifying the actual method by which the mobile node can use tunneling when participating in a routing protocol with the home agent. Another patent issue received significant attention. The editor, who submitted the patent disclosure for IBM, stated that he has obtained a statement of policy by IBM which complies with the official requirement of the IETF, but which does not really meet the needs of the participants in the MOBILEIP Working Group. He also said that meeting the needs is a time-consuming and tedious job which will proceed at a pace which, while not rapid, will hopefully produce timely results. John Tavs from IBM mentioned his view that there was no likely mechanism by which IBM would pursue the collection of royalties, but this was not viewed as sufficient to allay the fears of those implementing the specification for use in products. The general sense is that the editor is expected to get a better resolution of the patent issue, but that the current situation is good enough to proceed with implementation. Tony Li stated that if IBM does not make the technology available on suitably favorable terms, he would direct his efforts towards making fundamental changes to the specification so that there would be no use of patented technology. When the FA tries to contact the HA, it is possible for the FA to get back an ICMP error message. In this case, the group decided to create a new failure status code, so that the mobile node could determine that it should attempt to register with a different home agent (if possible). The new status code will be called ``Home Agent Unreachable''; no distinction will be made to reflect the various types of ICMP error messages which might be returned to the foreign agent. There was discussion about the bad things that might happen when a foreign agent crashed. Specifically, it was felt that a mobile node might have difficulty if it dropped packet 0 or packet -1 just at the time the foreign agent crashed. It was decided to require that the foreign agent must start its sequence of advertisement at 256 after a reboot. This will give the mobile nodes 256 opportunities to hear the foreign agent's advertisements and discover that the sequence number had wrapped around, instead of erroneously determining that the foreign agent had crashed. It was agreed to create a new status code for informing the mobile node, upon successful registration, that simultaneous registrations are not accepted by the home agent. This was intended to eliminate the following unfortunate scenario: The mobile node begins to enter a new service area for a foreign agent. If the mobile node believes that simultaneous registration is possible, then it may issue a request for same. Under the previous existing scheme, if the home agent grants the request, the first registration is revoked, and the mobile node would be stuck with a single registration in a suboptimal service area. With the new scheme, the mobile node will know as soon as it first registers with its home agent, whether simultaneous registrations are allowed. These were all the major substantive issues that people in the working group meeting could think of for discussion. Since the group had come to some conclusion on all of them except for the issue of registration without knowledge of any home agent address, the group decided in the afternoon to revisit the tabled question and quite good progress was made. The following approaches to the problem were identified: 0. Use the mobile node's address. Pro: Trivial for the mobile node. Con: Cannot work the first time when the mobile node moves away from the home network, since the home agents cannot tell that they need to start intercepting packets addressed to the mobile node. This alternative was eliminated right away because no one could argue against the Con: objection. 1. Use the subnet broadcast address, .<0> or .<-1>. Pro: Trivial for mobile node. Con: Problems with multiple home agents. It was claimed that most, but not all, entry routers into a home network would be able to successfully relay such subnet broadcast packets onto the home network. 2. Use DNS to get a ``Home Address'' record for the mobile node (as proposed by Greg Minshall on the mailing list). Pro: Uses established mechanisms. Con: Lots of packets exchanged. The foreign agent could actually do the work on behalf of the mobile node as part of the registration request sequence. This method would need a new resource record (HA), but it is going to be needed anyway. 3. Use a predetermined unicast address e.g, .1. Pro: Guaranteed to work with existing routers. Con: Possible overload of whichever single HA is providing service at that address. It was claimed that this was effectively pushing ARP into service as a routing protocol (a bad thing). This approach uses part of the subnet address space. There might be trouble if there are multiple groups per subnet. If there are multiple groups on the subnet, then there are presumably multiple groups of HAs, all of which would want to use .1, and only some of which would accept the registration. 4. Could use a predetermined list of unicast addresses. This variant of (3) overcomes the objection of possibly overloading any particular home agent. 5. Bag it. Pro: Not much, except that it reduces the amount of discussion time needed. Con: Unacceptable additional configuration requirement for mobile nodes. 6. Preregistration via subnet broadcast address. Pro: Auto-discovery mechanism already available in existing specification, if another field is added to the registration reply failure return. Con: Extra round trip at bootup; foreign agents need to keep some extra state on mobile nodes. Foreign agents need to permit registration packets to subnet broadcasts and forward replies to MN's even if they have not seen the HA's address before. Prior to this, the FA knew which HA was being registered with and could block packets for addresses other than that HA. This possibly exacerbates the existing covert channel provided by registration requests and replies. Alt: Home agents could wait a random time before responding. Alternatives (1), (2), (4), and (5) were eliminated from consideration after a great deal of productive discussion, and alternative (6) was a latecomer which was proposed after those above mentioned alternatives were eliminated. No final decision was reached, and after a while the suggestion was made to pursue the matter on the mailing list. However, it was the sense of the editor that alternative (6) was well received by the group. Since there was still time, Charles Perkins (not speaking as the editor) made an impromptu presentation of the recent route-optimization draft proposal. This proposal is available as draft-ietf-mobileip-optim-00.txt on the IETF draft directories, for anonymous FTP. The basic operation was outlined, with explanation of the need for ``Binding Notify,'' ``Binding Request'' and ``Binding Acknowledgment'' packet types. Mention was made of the idea of ``Simple Authentication,'' and how it might be applied to the route optimization document. Tony Li (co-chair) pointed out that the route optimization proposal would be unlikely to find acceptance by the area director if simple authentication were included in the draft. He suggested that a ``base'' draft of the route optimization proposal be developed first. He also suggested that an Informational RFC could be produced as a companion document for the route optimization proposal, and that implementors interested in offering the less stringent authentication mechanism would probably be interested in standardizing on the information approach, depending upon market acceptance. Charles Perkins accepted the responsibility of coordinating the interoperability testing of implementations produced by the next IETF meeting in Danvers. A handful of organizations indicated that they plan to begin implementation of the latest draft. Tony Li mentioned that he could possibly volunteer to get some equipment together to help the implementors, but no firm commitment yet. The editor hopes to release a new draft of the mobile-IP document in a couple of weeks.