Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4)

[Sri Gundavelli <[e-mail]>]

One correction.

> May 2010 Multiple tunnel support and flow binding (Experimental) to IESG
>

This is supposed to be on standards track.

Sri


On Tue, 18 Aug 2009, IESG Secretary wrote:

> The Mobility for IPv4 (mip4) working group in the Internet Area of the
> IETF has been rechartered.  For additional information, please contact the
> Area Directors or the working group Chairs.
>
> Mobility for IPv4 (mip4)
> -------------------------
> Last Modified: 2009-08-18
>
> Additional information is available at http://tools.ietf.org/wg/mip4
>
> Chair(s):
> Henrik Levkowetz <[e-mail]>
> Pete McCann <[e-mail]>
>
> Internet Area Director(s):
> Ralph Droms <[e-mail]>
> Jari Arkko <[e-mail]>
>
> Internet Area Advisor:
> Jari Arkko <[e-mail]>
>
> Mailing Lists:
> General Discussion: [e-mail]
> To Subscribe: [e-mail]
> In Body: subscribe
> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html
>
> Description of Working Group:
>
> 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.
>
> Goals and Milestones:
> Done AAA Keys for MIPv4 to IESG
> Done MIPv4 VPN interaction problem statement to IESG
> Done Low latency handover to experimental
> Done Experimental MIPv4 message and extensions draft to IESG
> Done Dynamic Home Agent assignment protocol solution to IESG
> Done Revised MIPv4 Challenge/Response (3012bis) to IESG
> Done Regional registration document to IESG
> Done Generic Strings for MIPv4 (Proposed Std.) to the IESG
> Done MIPv4 Mobike interaction (BCP) to the IESG
> Done MIPv4 RADIUS Extensions Requirements to the IESG
> Done MIPv4 Extension for Config. Options (Proposed Std.) to the IESG
> Done FMIPv4 (Experimental) to the IESG
> Done MIPv4 VPN interaction (BCP) to the IESG
> Done Base MIPv4 Mobile Network Support (Draft Std.) to IESG
> Done Dual-stack MIPv4 (Draft Std.) to IESG
> Done Notification Mechanism (Draft Std.) to IESG
> Jul 2009 Revised MIPv4 specification (Proposed Std.) to IESG
> Jul 2009 Revised MIB for MIPv4 (Proposed Std.) to IESG
> Aug 2009 NEMO Dynamic Address Assignment (Proposed Std.) to IESG
> Nov 2009 GRE Key Extension (Proposed Std.) to IESG
> Nov 2009 Revised rfc2794bis (NAI extension) (Proposed Std.) to the IESG
> Nov 2009 RADIUS Extensions for MIPv4 to the RADEXT WG for comment
> Dec 2009 MIB for UDP encapsulation (Proposed Std.) to IESG
> Feb 2010 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG
> Mar 2010 Home Agent Assisted Route Optimization (Experimental) to the IESG
> Apr 2010 Multicast/Broadcast delivery style (Proposed Std.) to IESG
> May 2010 Multiple tunnel support and flow binding (Experimental) to IESG
>
> --
> Mip4 mailing list: [e-mail]
>    Web interface: https://www.ietf.org/mailman/listinfo/mip4
>     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>