CURRENT_MEETING_REPORT_ Reported by Kannan Alagappan/Digital Equipment Corporation Minutes of the IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP) The Mobile IP Working Group met twice during the Toronto IETF. The major focus of these meetings was to discuss the remaining open issues in the current base protocol and draft for mobile IP. Agent Discovery It was questioned again whether support for agent discovery and roaming detection at the IP layer needs to be provided, and if so, how this should be done in cooperation with any assistance from various media-specific lower-layer protocols and in light of any administrative or policy issues. Questions included how to initially choose an agent from the advertisements received and when to possibly switch agents upon hearing of a ``better'' one in some new advertisement. It was agreed that an IP protocol for agent discovery must be provided that could be used possibly where no other support is available, but a clear consensus was not reached on the exact mechanism to be used. After much discussion, the chair stated the following mechanism: In the absence of link-level indications, a mobile node which already has an association with a foreign agent would continue that association (even in the presence of newly received advertisements from other foreign agents) until either (1) upper-layer protocols on the mobile node have expressed ``frustration'' or (2) the mobile node would normally attempt to re-register with its foreign agent. When initially searching for an agent with which to register, the group decided that a mobile node should listen for some time period (possibly zero) to collect advertisements before choosing one. This time period should probably be configurable, but the group did not decide on what the recommended period should be. Further discussion of this issue was deferred to the mailing list. The chair also suggested adding wording around this section in the draft explaining that other mechanisms for choosing a foreign agent were likely to be an area of some experimentation during the initial stages of interoperability and other testing. One possibility raised during the meeting but not discussed due to lack of time was to, instead, allow reregistration when a ``better'' agent was discovered, but to do something to dampen the maximum registration frequency to avoid thrashing. The way in which the draft currently discusses possible link-level agent discovery methods, such as its discussion of PPP, was questioned. The draft now implies that the described methods are the only possible methods, but in fact, there are likely to be many other methods for different types of network media. It was suggested by some that this section in the draft was incomplete, or that it was inconsistent, or that it should simply be removed entirely from the draft and left to be specified elsewhere for each type of media. No decision on this issue was reached though, and future discussion of it was deferred to the mailing list. Another question raised was whether the lifetime of a registration could be different from the lifetime in the agent advertisement. It was agreed that these could be different. The lifetime of an agent advertisement is the time before which a mobile node should expect to receive another advertisement from the same agent, in order to verify that the agent is still alive. The lifetime of a registration is the time period for which the registration (once completed) remains valid and the home agent and foreign agent agree to cooperate to forward packets for the mobile node. A question related to these two lifetimes raised during the meeting was whether to allow advertisements more frequently than one per second (the existing lower limit in the ICMP router discovery protocol). If the advertisement lifetime and the registration lifetime were required to be the same, allowing advertisements more frequently than one per second (which means an advertisement lifetime of less than one second) would force reregistration this frequently as well. Since it was agreed that the two lifetime values could be different, it was agreed that advertisements could be sent more frequently than the current limit of one per second. In this discussion, it was also decided to place a separate limit on how frequently a mobile node could reregister with its agent. This implies that a mobile node should not send reregistration attempts more frequently than this, and that a foreign agent should not try to impose a registration lifetime of less than this. The group did not decide what an appropriate lower limit on reregistrations should be, though. A question was also raised about the preference levels listed in an ICMP router discovery message in which a mobility extension also appears (an agent advertisement message). As defined now, there is only a single list of preferences in the message, and thus the existing meaning for router discovery is possibly being overloaded. Perhaps a system administrator should be able to configure one set of preferences for the advertised addresses for router discovery, but to have a separate set of preferences advertised for agent discovery. Discussion of this issue was deferred to the mailing list due to lack of time in the meeting. Agent Advertisement ``Mobility Extension'' It was suggested that a method is needed for a mobile node to recognize from an agent advertisement if the advertising agent is only a home agent (and thus does not support any foreign registration) or if it is only a foreign agent (and thus does not support home registration, even though it may be located on the home network for some particular mobile nodes). There are really four cases to be covered: o If an agent is neither a home agent nor a foreign agent, it will not include the mobility extension in its ICMP router discovery advertisements, and thus will not be mistaken for an agent by any mobile nodes. o If an agent is a home agent but not a foreign agent, it must advertise so that its client mobile nodes can notice it and detect when they have returned home. The group decided to add a bit in the mobility extension to indicate whether an agent is functioning (at least in part) as a foreign agent. In this case, this bit would not be set in its advertisements, allowing mobile nodes looking for a foreign agent to not waste its time and their own time attempting to register with it. o If an agent is a foreign agent but not a home agent, it will simply advertise as normal with a mobility extension. The bit should be set indicating that it is functioning as a foreign agent. Mobile nodes must be able to recognize the advertisements of their own home agents, presumably because they recognize the IP address of their own home agents, and thus will not attempt home registration with this agent. o If an agent is both a foreign agent and a home agent, it will advertise as above. Since it is the home agent for some mobile nodes, they will be able to recognize this for themselves by checking the IP address of the agent from the received advertisement. It was suggested that a way is needed for an agent to deregister one or more mobile nodes currently registered with it. This question broke down into the following three specific cases: o For an agent to deregister all existing mobile node clients, it should begin sending a lifetime value of zero in its multicast agent advertisement messages, for some number of advertisements. The group did not discuss how many such advertisements the agent should send, nor what to do if at least one of them was not received (or acted on) by one of its registered mobile node clients. o For an agent to deregister a specific individual mobile node client, it should unicast one or more agent advertisements to that client with a lifetime value of zero. As above, there was no discussion on how many such advertisements the agent should send, and what to do if at least one of them was not received (or acted on) by this specific mobile node client. The group also did not discuss how to handle any confusion that may be caused on the mobile node as it perhaps also continues to hear the regular multicast advertisements from the same agent, probably with a non-zero lifetime value. o To advise new clients that it is currently disallowing new registrations, a ``busy'' bit in the mobility extension of the agent advertisement message was added. The agent must continue to advertise so that its current clients can tell that it is still there and alive, but this bit will discourage new clients from wasting time attempting to register with it. It would be helpful for a mobile node to be able to detect from an agent's advertisements that the agent has just crashed and rebooted, and to be able to distinguish this from the sequence number in the agent's advertisements simply ``rolling over.'' The group decided that upon rebooting, an agent should multicast a ``reset'' signal in its advertisements for some small multiple of that agent's configured advertisement lifetime value. This reset signal will be sent as a normal agent advertisement with a reserved sequence number of zero in the advertisement. This implies that zero must not be used as a ``real'' sequence number value and that upon rolling over, the sequence number should increment from its maximum value to one, skipping the value zero. Two other suggestions were made to include additional information in the mobility extension: including the IP subnet prefix in the advertisement and including a list of other foreign agents on the same subnet in the advertisement. Both of these suggestions were withdrawn by their proposer. Packet Format/Protocol Issues It was asked if a single type field value could be used in the registration request message from the mobile node to the foreign agent, and from the foreign agent (or the mobile node) to the home agent. Right now, the draft specifies a different field from the foreign agent to the home agent, but this then complicates the authentication question in this case. By using a single value, this can be included uniformly in the computation of the authentication extension, and can be authenticated by the mobile node and simply passed through the foreign agent (since the foreign agent does not change the value) to the home agent. Then a bit is needed somewhere in the registration request message to distinguish between the message sent from the mobile node and that sent by the foreign agent. In our discussion of the mobility extension in the agent advertisement message, the request to include the IP subnet prefix in the advertisement was withdrawn (above). The group discussed here whether to allow this information to be added to the advertisement in another (different) extension. The group agreed that this is where this information properly belongs. This information is intended to possibly support whole mobile networks, rather than only simple mobile nodes. There was much discussion as to the correct address to use as the IP source address in the registration request packet sent to the home agent when a mobile node is registering in ``popup'' mode (acting as its own foreign agent, or registering without a foreign agent, depending on which philosophy you view it as). Some considered using the care-of address (the newly assigned temporary address) to be the most natural source address, but others argued just the same that using the home address of the mobile node was more natural. In the end, the group decided to use the care-of address, since using the home address instead would complicate returning a successful registration reply packet (it would have to be tunneled), would make it very difficult to return a rejection registration reply (how do you set up the tunnel from the home agent if the registration was rejected?) and would make it nearly impossible to correctly return any ICMP error messages to the mobile node that might possibly result from its registration request message. Replay Protection (Timestamp Versus Nonce) There was much discussion during the meeting, as well as before and after the meeting, on the subject of how to protect against replay of registration messages. Specifically, the issue was whether to use timestamps or nonces in the protocol. A group of participants met over dinner to discuss this topic and agreed on nonces. This was then raised before the whole working group in the meeting, and there seemed to be support for this method, but the group did not completely agree on this issue. If nonces are used, it was questioned what the correct size for the nonces should be, and the group agreed that 32 bits was the right size. In the end, on the issue of timestamps versus nonces, the group decided that the chairs will go to to Security Area Director(ate) with a brief on both proposals, and that the received advice will then be shared with the working group on the mailing list. It is suspected that if the advice strongly favors one of the proposals, the working group will adopt that proposal. In the absence of strong advice, the working group will further discuss the proposals on the mailing list and hopefully reach consensus on one of them. Additional Miscellaneous Topics The current draft states that a foreign agent must drop arriving encapsulated packets if it cannot deliver them locally to a visiting mobile node. It was asked if this ``must'' could be changed to a ``should,'' to allow room for smarter foreign agents to do something else to eventually get the packet to the destination mobile node. The fear here, though, is that a foreign agent that thinks it is smart but isn't could easily put the packet into a loop by trying something like this. The group acknowledged that extensions such as route optimization could override such a ``must'' when defining suitable smarter methods for foreign agents, but left unresolved whether to change the word in the base draft. This issue will be taken up on the mailing list. Some people thought that the wording in the current draft was inconsistent or incomplete in its description of how the authentication on registration packets was computed. One particular question was about which bytes of the packet were included in the authentication computation. In the draft now, sometimes the UDP header is included, and sometimes it is not included. Also, if it is included, it is necessary to specify what the UDP checksum should be set to when the authentication is computed. The group did not make any decision on this topic, but instead deferred discussion to the mailing list. It must be considered if there is a good reason to ever do authentication over the UDP header, and if there is no reason to, it should not be included. Also, if there is some reason to include it, it should be considered whether the IP header also needs to be included. The group talked for a short time about how to ease the configuration burden on a mobile node. In particular, this discussion referred to how to operate a mobile node without needing to configure into it the IP address of its home agent. For example, a site may want to change which of its hosts serves as the home agent while some of its mobile nodes are away from home, making it difficult to achieve this reconfiguration. Two suggestions were proposed. First, a mobile node could be allowed to use a directed broadcast to its home network, such as to inquire who its current home agent is. This request and its reply would need to be authenticated. The second suggestion was to have some type of records defined within the DNS to allow a mobile node to find its own (current) home agent address. This method, though, would require some cooperation from the mobile node's prospective new foreign agent that it is then trying to register with: the mobile node needs to find its own home agent address to register, but until the mobile node is registered, the foreign agent will not pass packets (such as the reply) to it. Discussion of this issue was deferred to the mailing list. The use of ``soft state'' for tunneling, as used in the current draft (and also used in IPAE), was questioned. In IPAE, the tunnels are fairly static in configuration, but in mobile IP they are likely to be much more dynamic, as mobile nodes move around. The question was whether soft state still works or is appropriate in this environment. Discussion of this question was deferred to the mailing list. When a mobile node leaves its home network, its home agent may send a gratuitous ARP for it, and when the mobile node later returns to its home network, the mobile node may send a gratuitous ARP for itself. The current draft states that each such use of gratuitous ARP may be sent only once, but it was suggested in the meeting that this restriction be relaxed to allow some small number of retransmissions in case of dropped packets. The group did not reach any decision on this issue and deferred discussion of it to the mailing list. Finally, it was suggested that people should think about what issues are involved in mobility for IPng, such as considering if any solutions that were rejected for IPv4 could now be made to work in an IPng world. The chair stated that for now, the group should concentrate on finishing IPv4 mobility, but Greg Minshall requested that people send thoughts on IPng mobility to him. Administrivia It was suggested that the group should have an implementors' meeting in October or November. Discussion of this meeting, including possible time and place, will take place on the mailing list.