• Current Meeting Report
• Slides
• Attendees List

IP Routing for Wireless/Mobile Hosts (mobileip)

NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.

Chair(s): 

Jim Solomon <solomon@comm.mot.com>
Erik Nordmark <nordmark@eng.sun.com>

Routing Area Director(s): 

Joel Halpern <jhalpern@newbridge.com>

Mailing Lists: 

General Discussion:mobile-ip@smallworks.com
To Subscribe: majordomo@smallworks.com
In Body: subscribe mobile-ip
Archive: ftp://ftp.smallworks.com/mobileip.archive/

Description of Working Group: 

The Mobile IP Working Group is chartered to develop or adopt architectures and protocols to support mobility within the Internet. In the near-term, protocols for supporting transparent host ``roaming'' among different subnetworks and different media (e.g., LANs, dial-up links, and wireless communication channels) shall be developed and entered into the Internet standards track. The work is expected to consist mainly of new and/or revised protocols at the (inter)network layer, but may also include proposed modifications to higher-layer protocols (e.g., transport or directory). However, it shall be a requirement that the proposed solutions allow mobile hosts to interoperate with existing Internet systems. 

In the longer term, the group may address, to the extent not covered by the mobile host solutions, other types of internet mobility, such as mobile subnets (e.g., a local network within a vehicle), or mobile clusters of subnets (e.g., a collection of hosts, routers, and subnets within a large vehicle, like a ship or spacecraft, or a collection of wireless, mobile routers that provide a dynamically changing internet topology).

Goals and Milestones:

Done		Review and approve the charter, making any changes deemed necessary.
Done		Post an Internet-Draft documenting the Mobile Hosts protocol.
Done		Review the charter of the Mobile IP Working Group for additional work required to facilitate non-host mobility.
Jul 96		Submit the IPv4 Mobile Host Protocol to the IESG as a Proposed Standard.
Dec 96		Submit the IPv6 Mobile Host Protocol to the IESG as a Proposed Standard.
Mar 97		Review the WG charter and update as needed.

Internet-Drafts: 

· Route Optimization in Mobile IP 

· Mobility Support in IPv6 

· Firewall Traversal for Mobile IP: Goals and Requirements 

· Reverse Tunneling for Mobile IP 

· Firewall Traversal for Mobile IP: Guidelines for Firewalls and Mobile IP entities

Request For Comments:

RFC	Status	Title
RFC1853	I	IP in IP Tunneling
RFC2002	PS	IP Mobility Support
RFC2003	PS	IP Encapsulation within IP
RFC2006	PS	The Definitions of Managed Objects for IP Mobility Support using SMIv2
RFC2004	PS	Minimal Encapsulation within IP
RFC2005	PS	Applicability Statement for IP Mobility Support

Current Meeting Report

Minutes of the IP Routing for Wireless/Mobile Hosts (MOBILEIP) Working Group 

Reported by: Frank Ciotti and edited by Jim Solomon

Mobile IPv4 – April 7, 1997 0930Dave Johnson reminded everyone about MobiCom 1997 September 26-30 

Budapest, Hungary

I. Jim Solomon -- PPP IPCP Mobile IP Option draft, <draft-ietf-pppext-ipcp-mip-00.txt> 

Main benefits: 

· Allows FA's to be deployed which have no means for assigning unique addresses to MNs. 

· Less wasteful of IP addr space - no unique IP addr assignment to MN unless one is required. 

Issues: 

Co-located COA assignment mechanism might be redundant with the IP-Address option semantics. Jim and Steve to investigate whether the IP-Address option can be used instead. 

Jim to present to PPPEXT Working Group and move the draft forward. 

Jim Solomon on behalf of Gabriel Montenegro -- Reverse Tunneling draft <draft-ietf-mobileip-tunnel-reverse-01.txt> 

Issues:

MN *MUST* use FA as ONLY rtr, not simply default router.
Major security hole with reverse tunneling: Bad Guy can conspire to get a FA to reverse tunnel the packets generated by a Good Guy to a bogus location [possibly causing a routing loop -- ed.].
Gabriel to address security concerns before this document moves forward.

Things to clarify in the draft: 

· Why use 16 bits for a 1-bit field in the Delivery Style Extension? Why not just use a "boolean" extension?

·   Should the Registration Reply contain a list of the types of encapsulation supported (IPIP vs MIN vs GRE)?

· If the MN is a router and is forwarding pkts, the MN should encapsulate the datagrams itself before sending them to the FA. 

· The draft states that the HA should only accept reverse tunneled packets from the MN's COA. This is incompatible with generic IP in IP encapsulation (e.g., tunnels unrelated to mobility) and provides no security since the COA can be spoofed anyway. 

Chairs expressed concern that, despite numerous requests, these issues had not been brought up on the mailing list before the meeting. 

II. Vipul Gupta -- Firewall Traversal draft, <draft-ietf-mobileip-firewall-trav-00.txt> 

Goals: Enable use of Mobile IP in the presence of multiple IPSEC firewalls and private addresses. 

Issues:

·   MTU can go to zero if there are large numbers of firewalls but usually there will only be one or two.
·   In future, all ESP transforms will have authentication too.
·   We should keep the requirement that the FW is not necessarily the HA and vice-versa.        
·   IPv6 provides site-local addresses which perpetuates the "private address" problem.  We should not drop "private addresses" as a requirement.
·   MIP is really first "consumer" of IPSEC services and IPSEC doesn't really address policy concerns which is why these issues are coming up.
·   The AFT Working Group is wrestling with internal nodes getting out through the firewall -- not external (authorized) nodes getting inside the firewall.

Open Issues: 

· How does MN discover all firewalls? 

· How does MN detect that it is "inside" versus "outside" the firewalls? 

Conclusion: We need to continue this exercise to see what develops in terms of requirements, particularly with regard to policy, for MNs, HAs, and firewalls. Whether the MOBILEIP working group goes beyond this, by specifying packet formats and message sequences, is unclear. The IPSEC Working Group might perform this latter activity. The chairs have requested help from the Security Area to assist in the firewall-traversal effort.

III. Steve Glass -- FTP Software Interoperability Testathon Results

18 attendees
10 implementations (6 corporations, 4 universities)
4 days of testing (lost 1 day due to Winter storm)
14 HA's, 13 FA's, 10 MN's
co-located COAs obtained by manual configuration
'R' bit tested with co-located MNs
reverse tunneling demonstrated
Jim Solomon and Frank Kastenholz put together a list of issues and will post them to the mailing list.
Steve Glass will post more detailed results to the mailing list.

To get to draft standard we need:

·   Significant campus type deployment experience (at least "a few" campuses with "many" people actually using MIP).
·   Traversal over public network required.

a. Dynamic HA address discovery

·   No directed broadcasts in IPv6;
·   IPng wg does not like the multicast-in-anycast tunnel discussed in San Jose because of denial-of-service attack;
·   IPng Working Group prefers a change which requires *all* IPv6 routers to recognize a "HA Discovery Anycast Packet" and emit it as an all-nodes multicast on home link.
·   Authentication isn't an issue because all HAs *reject* this anyway which, by definition, means they don't modify behavior as a result.
·   Is this an ICMP?  Destination Option?  UDP?  Other? 
·   Use of ICMP for HA Discover packet would make it easy for routers to process since they must already implement support for ICMP.
·   How will a MN find a HA on its home network if its home network is  renumbered while it is away?  The general consensus is that this is an administrative issue since the Home Address configured in the MN itself will also need to be modified at the time the Home Network is renumbered.

· We cannot use replay protection provided by IPSEC because Binding Updates *must* be applied *only* in order. Choices: 

1. Do our own replay protection.

2.   Convince IPSEC Working Group to modify their replay protection to allow us to select an in-order option.

3. Use IPSEC replay prot *and* our own sequence number.

The best choice seems to be #3 

· Lets IPSEC worry about re-keying before wrap around. 

· Lets us worry only about sequencing. 

· Similar to TCP seq # when using IPSEC replay protection. 

Most people agreed with this choice.

c. Multiple Routers on the Foreign Network 

Issues: 

MN can really only do neighbor unreachability detection with its default routerSolutions: 

Route packet to specific router:

·   Use a routing header to first go to the correct rtr, then to the COA.

· somewhat reintroduces the concept of FAs. 

· Fix the problem outside of Mobile IP: 

· This is a wireless problem, not a Mobile IP problem. 

· Most likely a problem together w/mip, though. 

Consensus: This is a wireless problem that needs to be fixed but not in the Mobile IP Working Group. Also, if this is an issue, don't architect the system such that transceivers on the *same* subnet have coverage overlap (i.e., make them separate links).

d. Movement Detection Timing 

Proposal: Add a field (e.g., a Nominal Advertisement Interval field) that lets MN know *exactly* how often the router is advertising such that the MN can know *exactly* when it has missed one. 

There were some concerns, but overall feeling is to submit the proposal to the IPng Working Group.

e. Other Issues 

Problem: If router B does not support sending a Binding Update to router A after the MN moves from A to B, packets may be dropped. 

Solution: The spec should be changed to say the lifetime of the Binding Update MUST (not SHOULD) be <= the registration lifetime. 

Problem: Ingress Filtering might prevent MN from sending pkt w/src addr = home address. 

Proposal: Both the MN and the CH use the care-of address instead of the MN's home addr. The MN also sends a router header to the CH to indicate the route back to MN home addr. If the CH ever loses the routing information (power loss), the CH will send the pkt to the care-of address, not the home address. The MN can detect it received the packet via its care-of addr, not home addr, and send a routing header to the CH. 

Continue discussion on mailing list. 

Slides

Attendees List