NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 22-Jan-98
Chair(s):
Erik Nordmark <nordmark@eng.sun.com>
Jim Solomon <solomon@comm.mot.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Routing Area Advisor:
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/mobile-ip.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 Support for Mobile IP
· 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
· IP Mobility Support version 2
· Registration Keys for Route Optimization
· Special Tunnels for Mobile IP
· Tunnel Establishment Protocol
· Rapid Authentication for Mobile IP
· Use of IPSec in Mobile IP
· Support for Mobile IP in Roaming
Request For Comments:
RFC |
Status |
Title |
RFC1853 |
IP in IP Tunneling | |
RFC2005 |
PS |
Applicability Statement for IP Mobility Support |
RFC2004 |
PS |
Minimal Encapsulation within IP |
RFC2003 |
PS |
IP Encapsulation within IP |
RFC2002 |
PS |
IP Mobility Support |
RFC2006 |
PS |
The Definitions of Managed Objects for IP Mobility Support using SMIv2 |
Minutes of the IP Routing for Wireless/Mobile Hosts (mobileip) Working Group
Co-chairs:
Erik Nordmark, Sun Microsystems, <nordmark@eng.sun.com>
Jim Solomon, Motorola, <solomon@comm.mot.com>
Minutes by: William Fisher <fisher@hollywood.engr.sgi.com>
Heavily edited by: Jim Solomon <solomon@comm.mot.com>
I. IPv4 Update (Jim Solomon, Motorola)
1. Mobile-IPv4 Configuration Option for PPP IPCP <rfc2290.txt> => now a PROPOSED STANDARD RFC.
2. Reverse Tunneling for Mobile IP, <draft-ietf-mobileip-tunnel-reverse-05.txt> = > awaiting IESG Last Call for PROPOSED STANDARD RFC.
3. Firewall Support for Mobile IP <draft-montenegro-firewall-sup-03.txt> => awaiting IESG Last Call for INFORMATIONAL RFC.
Issues
Encapsulator use and honoring of the 'DF' flag -- Some (broken!) hosts are setting DF and not backing off when they receive ICMP Destination Unreachable (fragmentation needed and DF set). Proposal to change RFC2003 to say that an encapsulator SHOULD set DF bit in encapsulating packet instead of MUST. Observation that this breaks Path MTU discovery for well-behaved hosts. [It turns out that the ICMP Unreachable was being filtered by a firewall and never arrived at the correspondent host. This is a deployment issues that needs to be understood and documented. -- JDS].
[Perkins] Are we ready to go to Draft Standard from Proposed Standard for RFC 2003?
[Solomon] We don't have sufficient implementation experience.
II. Mobility Support in IPv6 (David Johnson, CMU)
Consensus on the following items from IPNGWG:
· Add (H) bit in Router Advertisements to allow home agents to send a list of candidate home agents to mobile nodes doing Dynamic Home Agent Address Discovery;
· New Advertisement Interval option for Router Advertisements to allow mobile nodes to actively determine when they've missed one;
· Allowing routers to advertise more frequently than specified in base IPv6 document(s) in order to provide better service to mobile nodes.
Unresolved issues:
· IANA: Steve Deering and Dave Johnson to make a proposal regarding carving up the unicast space for anycast addresses; Bob Hinden will serve as clearinghouse for the various option codes required by Mobile IPv6;
· How do IPv6 implementors learn of the requirements conferred upon them by Mobile IPv6; namely, that *all* IPv6 implementations MUST process the Home-Address Option? Proposal to list all documents specifying such obligations on the IPNGWG web page until a "real" requirements RFC can be written.
Since router advertisements are sent from link-local address, how does mobile node ever learn home agent's global address? Consensus that a Global Address option (extension?) could be defined for Router Advertisements in which Home Agents can place their global address.
Consensus that no one is really capable of defining what a "site" is in the IPv6 architecture; thus, what should the Mobile IPv6 document say about forwarding such addresses to mobile nodes by home agents? In order to make progress, there was some consensus that we say that an HA SHOULD forward site-local addresses and that this behavior SHOULD be configurable.
Consensus on not adding new mechanism to distinguish preference among the list-o-routers returned to a mobile node performing Dynamic Home Agent Address Discovery.
Discussion about Mobile Networks, though it is uncertain what is being lost in IPv6 compared to IPv4 mobility. After further review, it is not obvious how to optimize routing to a "mobile passenger"; i.e., someone mobile with respect to a piece of topology that is itself mobile with respect to the rest of the Internet. Dave to clarify this in the draft.
Consensus on "Binding Multiple Home Addresses": if a mobile node has multiple addresses, then it needs to send different Binding Update options for each and every such address. Consensus not to try to define an N-way Binding Update option.
III. IP Private Address Identification (T. Teo, NUS)
Microphone Q/A:
1) Why do you need PAID, Why not use SNAP?
2) Why not use reverse tunneling and NAT today since it works?
Presenter Answer:
What mechanisms are used in Mobile IP to implement this today, Registration Messages!
3) What are the real benefits here, when adding the extra headers?
Presenter Answer: Wait until the next presentation is shown.
IV. Mobile IP extension for Private Internets Support (Y. Li, Bay Networks)
Microphone Q/A:
1) PAID added after beginning and really work together. MVPN Agents installed on Border.
2) Are they expected to have knowledge to parse PAID headers
3) Registration Process
4) Regarding the Firewall Reversal Draft, how does this compare?
a) The firewall draft does not address the presentation process
b) Can also remove a Foreign Agent with PAID in certain instances.
Dynamic Home Agent Address Discovery
Mobile Ipv6: Recent Changes and Open Issues
The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks
IP Private Address Identification (PAID)
Mobile IP Extension for Private Internets Support