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 specs to DS, the MIPv4 NAI RFC (2794) will be revised
to reflect implementation experience
2. Work items that are pending from the previous Mobile IP WG, which
will be completed by the MIP4 WG, are:
- completion of the MIB for the revised base Mobile IP
specification (2006bis)
- regional registration draft.
3. The MIP4 WG will also complete the work on MIPv4 interactions
in VPN scenarios. This work will involve identifying the requirements
and a solution development for MIPv4 operation in the presence
of IPsec VPNs.
4. Additionally, a proposal has been made for how MOBIKE could work
together with MIPv4. This proposal does not describe any new protocol,
but formulates a best current practice for deploying MOBIKE together
with MIPv4. The working group will adopt and complete this document.
5. Some issues have been raised with respect to RFC3519. These will be
identified and addressed as appropriate, through errata, revision
of RFC 3519, and/or supplemental documents as needed.
6. It has been proposed that the FMIP protocol, which has been
standardised for MIPv6 in the MIPSHOP working group, should also be
published as an experimental protocol for MIPv4. A draft for this
exists. The working group will take up and carry this work forward
to publication
7. An extension to carry generic strings in the Registration Reply
message has been proposed. The purpose is to supply supplemental
human-readable information intended to the MN user. The working
group will complete the specification and applicability statement of
such an extension.
8. RADIUS attributes for MIP4. A set of RADIUS attributes has
been proposed for MIPv4.
The working group will first produce a requirements specification,
describing how the work differs from the requirements in RFC 2977
and the functionality provided by RFC 4004 (the MIPv4 Diameter App).
The reason why this first step is required is that RFC 3127 pretty
clearly shows that full 2977 functionality can't be provided by even
a considerably extended RADIUS, so we need to match the requirements
to what can be done within RADIUS.
Provided the requirements work finds approval with ADs and radext,
the workgroup will complete the specification of MIPv4 RADIUS
attributes, solicit feedback from the Radius Extensions WG, adjust,
and submit this for publication.
9. MIPv4 Extension for Configuration Options.
Several drafts have proposed extensions to help improve configuration
of MIPv4 clients. The latest proposal is for a general configuration
option extension which could carry information such as e.g., DNS
address and DHCP server address. The working group will take on
and complete one proposal for a configuration option extension.