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

From: IESG Secretary <[email-masked]>
Date: Tue, 25 Jul 2006 16:00:01 -0400

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)
========================

Current Status: Active Working Group

Chair(s):
Peter McCann <[email-masked]>
Henrik Levkowetz <[email-masked]>

Internet Area Director(s):
Jari Arkko <[email-masked]>
Mark Townsley <[email-masked]>

Internet Area Advisor:
Jari Arkko <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
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 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 shows that
full RFC 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 WG,
the workgroup 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.

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.

10. Dual-stack Support

There have been several proposals for how to enable an IPv6 connection
over a network that supports Mobile IPv4. A protocol enhancement to
MIPv4 would allow for IPv6 support in a region where Mobile IPv4 has
already been implemented and deployed. This would allow a dual stack
mobile node to maintain IPv6 connectivity when using MIPv4. The
solution would therefore be applicable only to networks that are
not deploying Mobile IPv6.

The working group will take on and complete one proposal for IPv6 over
Mobile IPv4. This work is restricted to a small protocol extension
similar to current Mobile IPv4 functionality. Support for advanced
Mobile IPv6 functionality is strictly outside the scope.

A problem statement covering both Mobile IPv4 and IPv6 dual-stack
issues is expected to come out of MIP6 WG, and will not be developed
in MIP4 WG.

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
Aug 2006 MIPv4 Mobike interaction (BCP) to the IESG
Aug 2006 MIPv4 VPN interaction (BCP) to the IESG
Aug 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment
Aug 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG
Aug 2006 Revised MIPv4 specification to IESG for Draft Std.
Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG
Sep 2006 FMIPv4 (Experimental) to the IESG
Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG
Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG
Nov 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG
Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG
Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Pete McCann <[email-masked]>
Date: Wed, 26 Jul 2006 12:59:11 -0500

With the new charter item number 10, we are ready to start
work on a dual-stack Mobile IPv4 solution.  This note is
to query the working group to see whether we have consensus
on adopting

http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt

as that working group document.  Please send responses to
the list, stating whether you support the adoption of this
document.

-Pete

IESG Secretary wrote:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 29 Jul 2006 02:39:24 +0200

Pete McCann wrote:
> With the new charter item number 10, we are ready to start work on a
> dual-stack Mobile IPv4 solution.  This note is to query the working
> group to see whether we have consensus on adopting
> 
> as that working group document.  Please send responses to the list,
> stating whether you support the adoption of this document.

I support this as a WG item.  I have comments on it, sent separately.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 29 Jul 2006 03:07:01 +0200

draft-tsirtsis-v4v6-mipv4 describes three extensions to MIP4 header:
IPv6 Prefix Extension, IPv6 Code Extension and IPv6 Tunnelling Mode
extension.  The first and last are sent by MN if it does CCoA or by FA
otherwise.  The second is sent by HA.

> Extensions defined in this document allow a node that has IPv4 and 
> IPv6 [IPv6] addresses to maintain communications with either any of 
> its addresses while moving in IPv4 or dual stack networks.

I think there is scoping question here.  It seems to clash with what
DS-MIPv6 does.

I'd only care about DS-MIPv4 offering session continuity and
reachability at a permanent IPv6 address (not IPv4, MIP4 cares for that)
while connected to an IPv4-only network.

For completeness, we may think too that DS-MIPv4 would be MIP4
encapsulated in IPv6.  I.e. the access network is IPv6-only and the HA
is IPv4-only.  This draft demands HA to support both IPv4 _and_ IPv6
(because it does both proxy ARP and proxy ND).  I think this is not a
good idea, because, if we accept that there can be IPv6-only access
network then we also accept that there can be IP4-only home networks.  I
don't think it's good to demand HA to be placed always at the junction.

> 3.6. Dynamic IPv6 Prefix allocation

This section describes how to put ::0 in RegReq and obtain an IPv6
prefix in RegRep.

When MN is connected to an IPv4-only access network, it could open the
MIP4 UDP tunnel and run DHCPv6-Prefix Delegation on it and thus HA
delegates an IPv6 prefix to MN.

Finally, I think it would be good to suggest that this spec (DS-MIPv4)
extends the IPv4 Prefix Table of NEMOv4 (an informational draft in the
NEMO WG) to contain pairs of IPv6 prefix-IPv6 Home Address.  The NEMOv4
draft has this Prefix Table as IPv4-only.  It is manually configured by
admin and used to verify a certain IPv4 HoA can use a certain IPv4 MNP
(mobile network prefix).  Without extending the NEMOv4 Prefix Table with
IPv6 addresses the DS-MIPv4 HA may be prone to some security risks.

Alex

---

From: "Tsirtsis, George" <[email-masked]>
Date: Sun, 30 Jul 2006 10:27:51 -0700

Alex, comment inline...

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Friday, July 28, 2006 9:07 PM
> To: Pete McCann
> Cc: [email-masked]; Henrik Levkowetz
> Subject: Re: comments on draft-tsirtsis-v4v6-mipv4 (was: [Mip4] WG
> Action:RECHARTER: Mobility for IPv4 (mip4))
> 

GT> Alex, on the face of it, what you are saying here does not seem to
make sense. DS-MIPv4 is a simple extension to MIPv4. So, DS-MIPv4 is
likely to be a super-set of MIPv4. It would actually be hard to remove
feature that are present in MIPv4 as we extend the protocol to DS-MIPv4.

> don't think it's good to demand HA to be placed always at the
junction.

GT> You bring up two points: (i) IPv6-only access network and (ii)
IPv4-only home network. The draft proposal does not currently deal with
IPv6-only access networks. WRT (i) we could indeed deal with this but,
personally, I do not think this is an important case and we can always
extend the protocol further when something like that is needed. (ii) has
been discussed a number of times during the WG meeting and on the list
and I think you are alone in thinking that there is an issue here. Since
you seem convinced this is indeed an issue, you could write a draft,
describing the problem and suggesting some solutions...so we can discuss
it further. 

> delegates an IPv6 prefix to MN.

GT> This sounds like an option that is worth exploring.

> IPv6 addresses the DS-MIPv4 HA may be prone to some security risks.

GT> Yes, I agree.

Thanks
George

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 30 Jul 2006 20:12:09 +0200

Tsirtsis, George wrote:
>>> Extensions defined in this document allow a node that has IPv4 
>>> and IPv6 [IPv6] addresses to maintain communications with either 
>>> any of its addresses while moving in IPv4 or dual stack networks. 
>>> 
>> I think there is scoping question here.  It seems to clash with 
>> what DS-MIPv6 does.
>> 
>> reachability at a permanent IPv6 address (not IPv4, MIP4 cares for
>>  that) while connected to an IPv4-only network.
>> 
> 
> GT> Alex, on the face of it, what you are saying here does not seem 
> to make sense. DS-MIPv4 is a simple extension to MIPv4. So, DS-MIPv4 
> is likely to be a super-set of MIPv4. It would actually be hard to 
> remove feature that are present in MIPv4 as we extend the protocol to
>  DS-MIPv4.

Ok, it's everyone's interpretation.

I wouldn't scope both DS-MIPv6 and DS-MIPv4 to offer session continuity 
and reachability at a permanent IPv4 Home Address with v4-only, 
especially when MIP4 does it too.

>> encapsulated in IPv6.  I.e. the access network is IPv6-only and the
>>  HA is IPv4-only.  This draft demands HA to support both IPv4 _and_
>>  IPv6 (because it does both proxy ARP and proxy ND).  I think this 
>> is not a good idea, because, if we accept that there can be 
>> IPv6-only access network then we also accept that there can be 
>> IP4-only home networks. I don't think it's good to demand HA to be
>>  placed always at the junction.
> 
> IPv4-only home network. The draft proposal does not currently deal 
> with IPv6-only access networks. WRT (i) we could indeed deal with 
> this but, personally, I do not think this is an important case and we
>  can always extend the protocol further when something like that is 
> needed. (ii) has been discussed a number of times during the WG 
> meeting and on the list and I think you are alone in thinking that 
> there is an issue here.

Ok, let's see what other comments you get.

> Since you seem convinced this is indeed an issue, you could write a 
> draft, describing the problem and suggesting some solutions...so we 
> can discuss it further.

Thanks for the invitation.

>> When MN is connected to an IPv4-only access network, it could open 
>> the MIP4 UDP tunnel and run DHCPv6-Prefix Delegation on it and thus
>> HA delegates an IPv6 prefix to MN.
>> 
> 
>> Finally, I think it would be good to suggest that this spec 
>> (DS-MIPv4) extends the IPv4 Prefix Table of NEMOv4 (an 
>> informational draft in the NEMO WG) to contain pairs of IPv6 
>> prefix-IPv6 Home Address.  The NEMOv4 draft has this Prefix Table 
>> as IPv4-only.  It is manually configured by admin and used to 
>> verify a certain IPv4 HoA can use a certain IPv4 MNP (mobile 
>> network prefix).  Without extending the NEMOv4 Prefix Table with 

Ok, thanks,

Alex

---

From: "Tsirtsis, George" <[email-masked]>
Date: Sun, 30 Jul 2006 11:17:58 -0700

> Sent: Sunday, July 30, 2006 2:12 PM
> To: Tsirtsis, George
> Cc: Pete McCann; [email-masked]; Henrik Levkowetz

GT> Yes but what does that mean? Both DSMIPv4 and DSMIPv6 allow a
binding between an IPv4HoA and a CoA. How would you NOT offer session
continuity?

> Thanks for the invitation.

GT> OK, the comment was kind of patronizing, sorry :-) Seriously though,
writing a draft would be a good idea. 

George

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 31 Jul 2006 17:45:12 +0200

Tsirtsis, George wrote:
>> Tsirtsis, George wrote:
>>>>> Extensions defined in this document allow a node that has 
>>>>> IPv4 and IPv6 [IPv6] addresses to maintain communications 
>>>>> with either any of its addresses while moving in IPv4 or dual
>>>>>  stack networks.
>>>>> 
>>>> reachability at a permanent IPv6 address (not IPv4, MIP4 cares 
>>>> for that) while connected to an IPv4-only network.
>>>> 
>>> GT> Alex, on the face of it, what you are saying here does not 
>>> seem to make sense. DS-MIPv4 is a simple extension to MIPv4. So, 
>>> DS-MIPv4 is likely to be a super-set of MIPv4. It would actually 
>>> be hard to remove feature that are present in MIPv4 as we extend 
>>> the protocol to DS-MIPv4.
>> I wouldn't scope both DS-MIPv6 and DS-MIPv4 to offer session 
>> continuity and reachability at a permanent IPv4 Home Address with 
>> v4-only, especially when MIP4 does it too.
>> 
> 

We aren't sync'ed, maybe because I missed to put the word "access" near
"v4-only" above.

DS-MIPv4 doesn't do anything special to bind an IPv4 HoA to an IPv4 CoA.
  If DS-MIPv4 MN accessed v6-only networks then it would have been
necessary to bind an IPv6 CoA to an IPv4 HoA (something that DS-MIPv6
doesn't do, MIP6 doesn't do and MIP4 doesn't do)[*].

For the text in your draft, my (own) reading were happier if it only said:

>>>>> MIP4 extensions defined in this document allow a node that 
>>>>> accesses an IPv4-only network to maintain communications at 
>>>>> its IPv6 Home Address(es) [see DS-MIPv6 for MIP6 extensions
>>>>> to achieve same effect].

How people read and understand this or the original text is of course a
matter of your evaluation.

Alex
[*]: we've discussed previously whether v6-only access networks are a
      necessary feature, or will ever be necessary.  Of course, I can't
      say for the moment.  If you guys have specific deployment scenarios
      where you know IPv6-only access networks don't happen then that's
      wonderful, deployments should drive protocol design.  The
      discussions I have for v6-only access networks, v4-only home
      networks and v6-only home networks are just exercises in a lab.
      That for it.