CURRENT MEETING REPORT Reported by Jim Solomon, Motorola Minutes of the IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP) The Mobile IP Working Group met twice at the Dallas IETF. The first meeting was focused on IPv4 mobility and the second was primarily concerned with IPv6 mobility. The organization of these minutes is by topic area: IPv4 then IPv6. IPv4 Mobility Administrative Note: The Mobile IP mailing list has moved. The new location is as follows: General Discussion: mobile-ip@smallworks.com To Subscribe: majordomo@smallworks.com In Body: subscribe mobile-ip Many thanks to Jim Thompson for continuing to maintain the mailing list. 1) Patent Issues The outstanding patent issues facing Mobile IP have been solved: a) Perkins Patent. Tony read the summary of the opinion from Hale & Dorr, the law firm hired with ISOC funds to determine the scope-of- infringement of Mobile IP with respect to IBM Patent #5,159,592. The working group being generally pleased with the opinion has decided to publish the specification "as is" (i.e. no major substantive changes) and pursue PS RFC. The opinion from Hale & Dorr will be published as the appendix in the specification. b) Nonce Patent. It has been difficult to obtain a specific statement from IBM as to whether this patent is being asserted as relevant to Mobile IP. A proposal to mandate the use of timestamps, while allowing the optional use of nonces, was accepted by the working group. 2) Spec. Issues a) Requirements of FA location with respect to MN (i.e. "one hop away") and of HA location with respect to MN's home network (i.e. "must have an interface on") are never specified. Dave Johnson will supply text to the author. b) Temporary COA--similar comment as in (a), namely, what is the relation between the COA and the MN's current location? Dave Johnson will supply text here as well. c) Extensions are being defined by this WG that apply to either ICMP Router Advertisement or Registration messages--but not to both. It should be clear that the Extension values for each of these come from respectively separate numbering spaces, that is, an Extension intended only for ICMP Router Advertisements (e.g. Mobile Service Extension) and an Extension intended only for Registration Requests (e.g., Mobile- Home Authentication Extension), could both have the same Extension number. This should be clarified in the document. The working group decided not to renumber the extenstion Type values. d) The document should say that the advertising period should be NOMINALLY 1/3 of the Lifetime in the RFC1256-portion of the Agent Advertisement. e) Can an Agent Advertisement contain zero Router Addresses? The consensus is "yes, it can". In such a case, the MN MAY use the IP source address of the Agent Advertisement as a default router. If the "Num Addrs" is non-zero, then a default router MAY be chosen according to the rules of RFC1256 wherein the IP source address of the Agent Advertisement is interpreted to be the "worst" choice for address of a default router. f) FAs MUST be routers, that is, an MN must be capable of communicating by sending its packets through the FA to which it has registered. g) Solicitations SHOULD be rate-limited more so than the once per second currently specified in the draft. For example, exponential backoff was suggested. Dave Johnson will supply text to the editor. h) There was much discussion about the usefulness of prefixes for MN move detection in wireless environments where subnets can overlap. Tony Li and Charlie Perkins will put suitable text in the draft to discourage the use of prefixes in environments (e.g. certain wireless configurations) where they could lead to problems. i) Timestamp replay protection is broken. Two registrations with different COAs but both timestamps within the synchronization window would cause the wrong mobility binding to be current at the HA. As an additional rule, the HA must not accept any timestamp from an MN that is less than the currently accepted one. j) Usage of ARP is underspecified or downright broken: 1) Consider an MN that is not within the wireless range of its HA (and thus registers with an FA) but is within the wireless range of a CH on its home network. If the MN hears the CH's ARP and answers it, problems can arise if the MN then moves out of the range of the CH. Thus, while registered with an FA, the MN MUST NOT answer ARPs from any nodes other than that FA. 2) The ordering of operations when a MN leaves home and/or returns home is underspecified/wrong. When a mobile node leaves its home network and detects movement to a foreign network, the following sequence should occur: o MN stops answering ARPs o MN sends Registration Request o if HA accepts registration, it: a) sends gratuitous ARPs for the MN b) starts Proxy ARPing for the MN endif o HA sends Registration Reply. When an MN returns home, the following ordering occurs: o MN begins answering ARPs o MN sends gratuitous ARP(s) o MN sends Registration Request(s) o if HA accepts registration, it: a) stops Proxy ARPing for the MN b) sends gratuitous ARPs for the MN endif o HA sends Registration Reply. k) Some confusion was detected with regard to mobile routers. The language in the draft should perhaps be clarified in this regard. l) Validity checks in 3.6.2.1 are wrong with respect to receiving Registration Replies with a Code indicating a rejection by the FA. In this case, no MN/HA authenticator is likely to be found and, instead, an MN/FA authenticator must appear if the MN and FA share a security association. Jim Solomon to supply text. m) A suggestion was made that an FA provide tunneling in the reverse direction to provide location privacy for MNs. It was determined that this needed much more protocol mechanism and is a good topic for discussion on the mailing list. That is, it will be deferred until after the current draft goes PS. n) A suggestion was made to provide a mechanism to supply a node with an indication of WHICH extension was unrecognized or malformed. It was decided that at the time extensions are defined, the mechanism by which error reporting occurs (e.g. new code field, a general-purpose "bad extension" extension) should be defined as well. o) The current language in the draft states that if an MN sets the 'B' bit in a Registration Request then it will receive a copy of "all" broadcasts on the home net. The spec. should say that it is a matter of configuration at the HA as to which broadcasts get tunneled to the MN. 3) Mobile IP Applicability Statement. An applicability statement, as required for advancement of Mobile IP to Proposed Standard RFC (cf RFC1264), has been written by Jim Solomon and will be submitted as an Internet-Draft early next week. 4) Mobile IP MIB(s). David Cong and Mark Hamlen of Motorola have written a draft MIB for Mobile IP which will also be submitted early next week as an Internet-Draft. The group agreed to appoint the forementioned as working group editors of the MIB document. Charlie Perkins has agreed to assist in this effort. 5) Advancement to Proposed Standard RFC. All the requirements of RFC1264 have been (nearly) completed. Thus, when Charlie updates the draft, a working group last call will be issued, followed by submission of the draft to the IESG. Minimum Encapsulation could be advanced as an Informational RFC but "IP in IP" encapsulation MUST be advanced on the standards track. The co-chairs will consult with the Routing Area Director as for the rules for advancing IP in IP Encapsulation along the standards track. 6) Other Topics The following topics were discussed which are not part of the base technical specification but are nonetheless important to the Mobile IP Working Group: a) Route Optimization Dave Johnson presented the route optimization proposal as defined in draft-ietf-mobileip-optim-03.txt. The proposal involves a mechanism for distributing authentic binding information to correspondents of mobile nodes. The key distribution problem is mitigated by having authenticated bindings sent by the home agent rather than the mobile nodes themselves. The authors stressed the need for feedback on their proposal from the members of the Mobile IP Working Group. b) DHCP Extension Charlie Perkins presented a new option to DHCP for Mobile Home addresses for IPv4. DHCP currently provides an IP address for the local subnet. The new option requests an address that the mobile can use as a home address as well as an address of a home agent. The value of the option is 68. More investigation is required to determine how the mobile node and home agent can be set up with a security association. c) IP Squared Kazuhiro Okanoue presented his work on route optimization using Double-IP Headers (IP Squared) based on the Sony VIP work. This proposal uses IP concatenation, which uses an encapsulating IP header with the same protocol number. Statistically, it would be possible to differentiate this from the real data. IP concatenation is used by the mobile node to send data. All intermediate routers learn that the sender of the data is indeed a mobile node and then cache its care-of address. Such routers can then shortcut the routes to mobile nodes. d) Virtual Home Agents Dave Johnson presented a method on how to solve the problem of crashing home agents. This approach uses an extra address for home agents, which elect a "real" home agent from among the group. Tony Li noted that Cisco has a patent pending which might be relevant to this technology. e) Hierarchical Foreign Agent Charlie Perkins presented a method for short-cutting the registration process by registering a list of foreign agents that form a hierarchical tree. When moving among leaves in the tree, registration messages need only be sent back as far as the common branching node within the tree. f) IPv6 Mobility Charlie Perkins presented an overview of his and Dave Johnson's IPv6 Mobility draft (see draft-perkins-ipv6-mobility-sup-02.txt). The working group reached consensus that this is the architectural framework to be adopted for IPv6 moving forward. Future revisions of the IPv6 mobility draft will thus be "official working group" documents. The remainder of these minutes summarize Charlie's presentation (notes taken by Tony Li): o Port IPv4 Mobile IP proposal over to IPv6, but add allowances for IPv6 flexibility. There is no installed base. Authentication is built into all nodes. We can include route optimization for effectively no cost because of authentication. o Foreign Agents are still useful in IPv6. They can do authentication, charge for connection services, produce or share a session key for new clients, negotiate compression, manage the local router. o Tunneling can use an IPv6 routing header. It provides a loose/strict source route, but done right and can be done in any packet. We may still want to do tunneling because the header is authenticated and thus only the source can insert a header into the packet. o Binding updates are new and come from the IPv4 route optimization proposal. The HA is responsible for updating the previous foreign agent and the correspondent node. Only the mobile node sends binding updates. o A binding update fits in a destination option. You can still register with your home agent to establish location. The MN still needs to register with the FA, so the registration is encapsulated and forwarded to the FA, and then relayed to the HA. o The FA can decapsulate incoming packets if they are encapsulated. The MN sends updates to CH, without acknowledgment. No routing header indicates that a binding is necessary. o Binding updates should be rate limited. Estimate the RTT and use this as an approximation for a rate at which to limit. One MAY send updates to all open TCP connections. o To do: o Define binding update destination option o Define binding ACK packet or option o All nodes must be able to process them o All nodes must be able to use and maintain a binding cache o All nodes must be able to tunnel their own packets o Insure that authentications works during registration o Issues: o Interaction with IPv4 correspondents and mobile mobiles o Hop count limitations may halve the diameter of reachability o Should beacons be on a separate multicast address for performance of non-mobile hosts?