Editor's note: These minutes have not been edited. Mobile IP Working Group Meeting Minutes 35th IETF Meeting Los Angeles, March 1996 Chairs: Jim Solomon and Tony Li Reported by John Zao The Mobile IP working group met twice on March 6th and 7th at the Los Angles IETF. The first meeting was focused on IPv6 mobility and the second was primarily concerned with IPv4 mobility. The organization of these minutes is by topic area: first IPv6 then IPv4. IPv6 Mobility ============= IPv6 Mobile IP Draft Walk Through --------------------------------- The first meeting started with Charlie Perkins presenting an overview of the working group's IPv6 Mobility draft, co-authored by Charlie and Dave Johnson's (see draft-ietf-mobileip-ipv6-00.txt). IPv6 Mobile IP Features + Invisibility of FA: Mobile Nodes will be able to construct care-of addresses using IPv6 neighbor discovery protocols and obtain subnet prefix. Hence, they can be the natural end of IP tunneling or other form of packet redirection. Explicit FAs are no longer needed. + Universal Mobility Support: All IPv6 nodes will be mobility aware. This implies automatic route optimization and thus lightens the load of HAs. + CH's Use of Routing Header for Packet Redirection: CH can place the care-of address of MN in routing headers and compute the packet authenticator. Only HA needs to use IP encapsulation to effect packet redirection because it can not alter the authenticator. + Addition of Destination Option for CH Binding Update + Packet Forwarding (still an open issue) IPv6 Mobile IP Requirements + All Nodes: mobility awareness - routing header support - c/o address caching (as part of Destination Cache) - binding update processing + Mobile Nodes: - motion detection - c/o address construction - IP decapsulation (of packets from HAs) + Mobility Agents / Routers: - IP encapsulation - binding update dispatch - MN proxy Questions and Discussions: Plenty of discussions arose on the issues of access control which led smoothly into the discussions of using Mobile IP with firewalls (the next agenda item). An issue was raised in regards to accounting with the absence of explicit FAs. IPv4 enforces the use of an explicit FA to relay registration messages by setting the R bit in the messages. Similar mechanism was felt to be needed to perform access control functions. However, the general consensus prefers to deal with the problem as a security issue for assigning local IP addresses -- a DHCP problem rather than a MIP problem. Authentication methods should be built into the address assignment scheme and IPv6 routers should be able to recognize bad local address and drop the packets. The use of RADIUS Working Group technology was also suggested. All these provides only a philosophical framework for possible solutions; no solid scheme was proposed. Firewall Issues --------------- A lengthy discussion took place regarding the issues of packet passing to MNs through the firewalls. Two different problems were identified: (1) passing MN packets through the firewalls FROM the FOREIGN SUBNET, and (2) passing MN packets through the firewalls INTO the HOME SUBNET. The first problem seems to be more difficult although the two problems may be equivalent in some situations. The difficulty of passing packets through the firewalls FROM the FOREIGN SUBNET is caused by the fact that firewalls drop packets which are not originated from hosts belonging to the local subnet, and the process will likely be performed without any warning such as ICMP error messages. The suggestion of hiding true source addresses of MNs will not work because future firewalls should be able to defeat similar host masquerading. The real solution can only come with embedding certain authentication tokens (negotiated between MNs and foreign firewalls) into the packets so that the identity of their true sources can be authenticated and accepted according to the security policy. The problem of passing MN packets through the firewalls INTO the HOME SUBNET is simpler because it should be easier for the MNs to set up certain mechanism with their home subnet so that they can authenticate themselves to the firewalls. These problems were recognized as generally applying to host mobility, not limited to IPv6 Mobile IP. Hence, the Working Group was concerned, at one point, about the impact of the problems towards the standardization of IPv4 Mobile IP. Decisions were finally made that the firewall traversal issues will affect many protocols besides Mobile IP. The Mobile IP Working Group will thus produce a description of the problems and prepare to accommodate the future solution of the problems as they arise in the IPv6 community. An attempt to address the simpler problem of passing packets INTO HOME SUBNETS was also suggested. Mobile Mesh Network BOF (added item) ------------------------------------ Ran Orr initiated a discussion on the relations between IPv6 Mobile IP and the work in Mobile Mesh Network (MMNet) BOF. With the recognition that the issues of MMNet form a superset of those of Mobile IP, the discussion was recommended to be conducted after the meeting. Alternative Design of IPv6 Routing Header (added item) ------------------------------------------------------ Fumio Teraoka (SONY) proposed a different design of IPv6 routing header which may help the MN packets to pass through the firewalls and leave the foreign subnets. His design exchanges the positions of MN's care-of address (COA) and home addresses in the IPv6 Header and the Destination Option Header: Mobile IP wg draft: Fumio's draft: IPv6 Hdr MN Home Address MN COA Dst Opt Hdr MN COA MN Home Address As a result, the IPv6 Header will contain the local care-of addresses of MNs and hence may have less of a problem traversing the firewalls. It was noted, however, that firewall technology would likely adapt to this situation and restrict packets so constructed. Discussions on firewall problems were triggered once again by the presentation and were centered around the effects of using different routing headers. Source routing will not work with firewalls; nor will simple encapsulation. Likely, packets needs to be tunneled through the firewalls by adding another level of encapsulation. Questions about special vs ordinary tunneling were also raised. IPv4 Mobility ============= The second meeting of Mobile IP working group put its focus on IPv4 mobility. It was conducted with the following agenda: Last Call for Discussions before Standardization of Basic Mobile IP [J.Solomon] Presentation of Broadcast / Multicast Extension of Mobile IP [C.Perkins] Presentation of PPP Mobility Extension of IPCP [B.Patel] Presentations of Hierarchical FA / Regional Registration Concepts [C.Perkins & D.Johnson] Modification in Route-Optimized Mobile IP [D.Johnson] Presentation of Route-Optimization with IP-squared Protocol [K.Okanoue] Presentation of Secure Domain-Based Mobile IP [J.Zao] Presentation of Ideas on a Firewall Traversal Extension [C.Perkins] Last Call for Discussions before Standardization of Basic Mobile IP ------------------------------------------------------------------- The Internet-Draft, "IP Mobility Support" , is in IESG Last Call for advancement to Proposed Standard RFC. At the meeting, a final round of discussion was called by working group Co-Chairman, Jim Solomon to address some concerns posted to the IETF mailing list. Explicit notification of the community about the final resolutions of these issues must be arranged before standardization of the protocol. - Implication of Patent Application by Panasonic. Joel Halpern (routing area director) mentioned that this is under review by the IESG. Panasonic/Matsushita seems willing to present their terms and conditions. - Correctness of ARP Broadcasting in Foreign Subnets. MNs should take every precaution necessary to prevent getting their home address into ARP caches of nodes on a foreign network. Preferably, the MN learns an FA's hardware address by listening to the Agent Advertisement. The MN should answer ARPs only from prospective/current FAs on any foreign media. - Reservation of Security Parameter Index (SPI) Following the practice of IPSec WG, Mobile IP WG will mark the lowest 256 SPI values (0 - 255) reserved and therefore unavailable for use in authentication extensions. - Loss of Synchronization of Nonce-Based Replay Protection during Fast Mobility Concern was raised that MN may not obtain the next nonce value from HA if it moves from the FA before completion of current registration. MN would then have to use an old nonce in the next registration and thus caused a registration failure. This problem was considered non-critical in all rapid movements among FAs for the new registration request will always be relayed by the new FA and cause the reply (of registration failure) to be send through the correct path, i.e. via the new FA to MN. MN can then extract the new nonce from the reply and obtain re-synchronization of nonces. The only problematic case arises when MN travels back to home subnet before completing the last registration. Since the deregistration request will be sent from the home subnet with MN home address, the reply of failure will be sent to the old FA instead of the true location of MN. A solution was suggested which requires HA to examine the source addresses of deregistration messages. If the messages are sent by MN directly then the replies of these messages will be sent to MN on the home network. In some implementations, this would involve temporarily brining down the MN's tunnel to send the registration request, and then reinstating the tunnel. - Definition of Start and End Time of Registration Periods Since the delay between registration requests and replies is not always negligible comparing with the lifetime of registration, it is important to specify the start and end time of registration period, and determine when the MN should initiate a re-registration. The discussion concluded that at the MN, the period should start at the time it sends the registration request, and end when the lifetime specified in the registration reply expires counted from the defined start. At HA, the registration period starts at the time the request is processed, and ends when the lifetime specified in the reply expires counted from the defined start. At the FA, it was suggested that the period should start when the request is forwarded and end when the granted lifetime expires, counting from the defined start time. Broadcast / Multicast Preference Extension of Mobile IP [C. Perkins] -------------------------------------------------------------------- Charlie Perkins and Baiju Patel proposed a Broadcast Preference Extension to the Mobile IP Registration Request message [see draft-perkins-mobileip-bcastpref-00.txt]. The extension allows a MN to specify the IP broadcast datagrams it wants to receive from its home network (via its HA). The Broadcast Preference extension may be included several times within a single registration request; each selects a particular kind of datagrams that the MN wants to receive. The extension specifies conditions on the protocol number and the port number, which must both be satisfied by the datagrams before the HA should forward them to the MN. It also provides four flags: C (Clean), P (Permanent), A (Additional) and X (Exclude) to specify the action to the list of selected datagrams that is caused by the extension. Comments were invited after the presentation especially on the additional constraints (beside of protocol and port numbers) necessary for selecting the broadcast / multicast datagrams. A question was raised by the audience on the difference between the use of P and A flags. The answer was that the selection marked by a P flag can only be cleared by an extension with C flag set while the selection marked by an A flag can also be cleared by an extension containing the same selection marked by an X flag. PPP Mobility Extension of IPCP [B.Patel] ---------------------------------------- Baiju Patel and Charlie Perkins also proposed a new option called the Mobility Agent Configuration Option to the IP Control Protocol (IPCP) in PPP protocol suite [draft-patel-mobileip-pppext-00.txt]. The option allows a requesting peer to determine whether the responding peer is capable of and willing to function as either home or foreign agent of Mobile IP. From the transaction, the requesting peer can also obtain a care-of address from the responding peer. The Mobility Agent Configuration Option will be sent by a PPP requesting peer with a valid IP address. When a PPP peer receives the option, it must respond with Configure-Ack, Configure-Nak or Configure-Rej to indicate if it can be a mobility agent and whether it will serve as a HA or a FA. In the FA case, a care-of address will also be dispatched. After the discussion, there was a discussion on the proper order to send IPCP messages with Mobility Agent Configuration and IP Address options. It is recommended that a mobile IP peer should first try to use the Mobility Agent Configuration option and then the IP Address option, if necessary. There was some question as to the need for the Mobility Agent Configuration option. Hierarchical FA and Regional Registration [C.Perkins & D.Johnson] ----------------------------------------------------------------- Increasingly, the Mobile IP community realizes the inefficiency of requiring the MNs to register with their HAs *every time* they change their FAs. The registration procedure may become too expensive (if the HAs are far away) or even impossible to complete (if partitions exist among networks).