Mobility for IPv4
charter-ietf-mip4-08

Document Charter Mobility for IPv4 WG (mip4)
Title Mobility for IPv4
Last updated 2003-08-21
State Approved
WG State Concluded
IESG Responsible AD Brian Haberman
Charter Edit AD (None)
Send notices to (None)

Charter
charter-ietf-mip4-08

IP mobility support for IPv4 nodes (hosts and routers) is specified in
  RFC3344. RFC 3344 mobility allows a node to continue using its
  "permanent" home address as it moves around the Internet. The Mobile
  IP protocols support transparency above the IP layer, including
  maintenance of active TCP connections and UDP port bindings. Besides
  the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal
  with concerns such as optimization, security, extensions, AAA support,
  and deployment issues.
  
  MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000
  networks). The scope of the deployment is on a fairly large scale and
  accordingly, the MIP4 WG will focus on deployment issues and on
  addressing known deficiencies and shortcomings in the protocol that
  have come up as a result of deployment experience. Specifically, the
  working group will complete the work items to facilitate interactions
  with AAA environments, interactions with enterprise environments when
  MIPv4 is used therein, and updating existing protocol specifications
  in accordance with deployment needs and advancing those protocols that
  are on the standards track.
  
  Work expected to be done by the MIP4 WG as proposed by this charter is
  as follows:
  
  1. MIPv4 has been a Proposed Standard for several years. It has been
  adopted by other standard development organizations and has been
  deployed commercially. One of the next steps for the WG is to advance
  the protocol to draft standard status. As part of advancing base
  Mobile IP specifications to Draft Standard, the MIPv4 NAI RFC (2794)
  will be revised to reflect implementation experience.
  
  2. The WG will complete the MIB specifications for the Mobile IPv4
  base protocol and the UDP tunneling extension.
  
  3. A requirements document for RADIUS MIP4 support was previously
  completed and published as RFC 5030. Based on these requirements,
  the WG will complete the specification of MIPv4 RADIUS
  attributes, solicit feedback from the RADEXT WG, adjust, and submit
  this for publication. Note that the work may require extensions to the
  RADIUS attribute space which will be handled outside the MIP4 WG.
  
  4. Like fixed nodes, mobile nodes sometimes need to be dynamically
  configured with parameters such as DNS server IP addresses. Previous
  work in the WG proposed to put a generic container for host configuration
  options into Mobile IPv4 signaling. However, it may be easier for
  mobile nodes to implement the already existing DHCP specification,
  and to run DHCP over the tunnel established with an initial registration.
  The WG will take on a draft describing any modifications to Mobile IPv4
  that may be needed to facilitate this mode of operation, and submit
  for publication as a Proposed Standard or Best Current Practice as
  appropriate.
  
  5. The proliferation of devices with multiple interface technologies
  and the desire to use each interface for the type of traffic most
  appropriate to it (even simultaneously with other interfaces active at
  the same time) has led to requirements for supporting multiple
  simultaneous tunnels between the Home Agent and Mobile Node. The WG
  will adopt and take to publication as an Experimental RFC one draft that
  describes how to manage such tunnels and how to direct traffic to use
  the appropriate tunnel when multiple choices are available. This work
  will be coordinated with similar Mobile IPv6 work ongoing in the mext
  working group. In particular, we will strive to converge on a consistent
  set of architectural decisions (such as which entities are responsible
  for signaling flow-to-tunnel bindings) and we will share protocol
  definitions wherever practical (such as the layout of packet flow
  filters).
  
  6. The WG has published a basic Network Mobility (NEMO) specification
  as RFC 5177. The WG has taken up an extension to NEMO that will
  allow for dynamic home network prefix allocation to a moving network.
  The WG will finish work on this draft and publish as a Proposed
  Standard.
  
  7. Route optimization has been the focus of a large amount of effort
  in the Mobile IPv6 WG. For Mobile IPv4, however, the usage case is
  less clear due to a variety of factors, including the inability to
  modify already deployed correspondent nodes. Recently a specific
  use case has been proposed involving route optimization for a more
  closed network where modifications are made to site routers and a
  centralized Home Agent to enable offloading of traffic from the
  Home Agent. The WG will take on and publish a draft on this topic
  as a Experimental RFC.
  
  8. The use of GRE tunneling with Mobile IPv4 enables support for
  multiple overlapping private address spaces within the same mobility
  agent. However, to distinguish flows from two different mobile nodes
  that happen to share the same (private) IP address, the GRE Key field
  needs to be populated with a unique identifier that will enable the
  mobility agent to demultiplex the flows. The value used for the Key
  needs to be signaled at the time of tunnel establishment, which means
  a new Mobile IPv4 extension is needed for this purpose. The WG will
  take on an publish a draft on this topic as a Proposed Standard.
  
  9. Support for multicast and broadcast packets in Mobile IPv4
  as specified in RFC 3024 currently requires encapsulated delivery
  style for all packets. This leads to inefficiencies on the
  MN-to-FA link because even unicast packets must be encapsulated.
  Eliminating this inefficiency is possible if there is a mechanism
  to negotiate a mode of operation where only multicast/broadcast
  packets are encapsulated, while unicast packets can use direct
  delivery style. The WG will take on a draft to solve this
  problem and publish as a Proposed Standard.