Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4)

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Jun 2006 17:49:38 +0300

FYI -- MIP4 wants to recharter to include work on dual stack
Mobile IPv4 support (item 10 below). Given that MIP6 also
works on related issues I wanted to point you to this update.
Comments welcome.

--Jari

IESG Secretary wrote:

>A new charter for the Mobility for IPv4 (mip4) working group in the Internet
>Area of the IETF is being considered.  The draft charter is provided below for 
>your review and comment.
>
>Review time is one week.
>
>The IETF Secretariat
>
>+++
>
>Mobility for IPv4 (mip4)
>==========================
>
>Last Modified: 2006-06-13
>
>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 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.
>
>10. Dual-stack Support
>
>There have been several proposals for how to enable an IPv6
>connection over a network that supports Mobile IPv4. The
>basic idea is to include an IPv6 address in the Mobile IPv4
>signaling messages. The working group will take on and complete
>one proposal for IPv6 over Mobile IPv4.
>
>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
>Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment
>Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG
>May 2006 MIPv4 Mobike interaction (BCP) to the IESG
>May 2006 MIPv4 VPN interaction (BCP) to the IESG
>May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment
>Jun 2006 Revised MIPv4 specification to IESG for Draft Std.
>Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG
>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
>Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG
>Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG
>  
>

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Thomas Narten <[email-masked]>
Date: Thu, 15 Jun 2006 12:29:55 -0400

> works on related issues I wanted to point you to this update.

Is there a well-defined problem statement for item 10?

Thomas

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Jun 2006 10:03:42 -0700

So I'm wondering if there is any work to be done here in addition to the 
draft that is currently being worked on in the MIP6 WG? If the only work 
involves having someone from the MIP4 WG review the draft, then is there 
really need for a new charter item? On the other hand, if there is need for 
another document describing the interaction between the MIP6 transition work 
and MIP4, then maybe there is need for a new charter item (but if that is 
true, I'd say it's a flaw in the MIP6 transition document, and it should be 
handled by updating that).

Also, is there a MDIR concall tomorrow?

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "Mobile IPv6 Mailing List" <[email-masked]>
Cc: "Peter McCann" <[email-masked]>; "Henrik Levkowetz" 
<[email-masked]>
Sent: Thursday, June 15, 2006 7:49 AM
Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 
(mip4)

---

From: Pete McCann <[email-masked]>
Date: Thu, 15 Jun 2006 12:14:33 -0500

The proposal is to do a MIP4 extension for handling IPv6 addresses.
This is distinct from the MIP6 work item which is to extend MIP6
to handle v4 addresses.

-Pete

James Kempf wrote:
> really need for a new charter item? On the other hand, if there is need 
> for another document describing the interaction between the MIP6 
> transition work and MIP4, then maybe there is need for a new charter 
> item (but if that is true, I'd say it's a flaw in the MIP6 transition 
> document, and it should be handled by updating that).
> 
> ----- Original Message ----- From: "Jari Arkko" <[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Jun 2006 10:20:51 -0700

Is there some reason why that couldn't be included in the transition 
document? Wouldn't it be more practical from an implementation standpoint to 
have the transition mechanism documented in one place, so implementors 
didn't have to go paging through the RFC Web site to track down all the bits 
and pieces they need to make it work?

            jak

----- Original Message ----- 
From: "Pete McCann" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; "Mobile IPv6 Mailing List" 
<[email-masked]>; "Henrik Levkowetz" <[email-masked]>
Sent: Thursday, June 15, 2006 10:14 AM
Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 
(mip4)

>> transition work and MIP4, then maybe there is need for a new charter item 
>> (but if that is true, I'd say it's a flaw in the MIP6 transition

---

From: Pete McCann <[email-masked]>
Date: Thu, 15 Jun 2006 12:25:49 -0500

One is a MIP6 extension, the other is a MIP4 extension.  It makes
sense to me to split this up and do the work on extensions to the
protocols in the working group for each protocol.

-Pete

James Kempf wrote:
> document? Wouldn't it be more practical from an implementation 
> standpoint to have the transition mechanism documented in one place, so 
> implementors didn't have to go paging through the RFC Web site to track 
> down all the bits and pieces they need to make it work?
> 
>            jak
> 
> ----- Original Message ----- From: "Pete McCann" <[email-masked]>
> Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for 
> IPv4 (mip4)
> 
> 
>>> So I'm wondering if there is any work to be done here in addition to 
>>> the draft that is currently being worked on in the MIP6 WG? If the 
>>> only work involves having someone from the MIP4 WG review the draft, 
>>> then is there really need for a new charter item? On the other hand, 
>>> if there is need for another document describing the interaction 
>>> between the MIP6 transition work and MIP4, then maybe there is need 
>>> for a new charter item (but if that is true, I'd say it's a flaw in 
>>> the MIP6 transition document, and it should be handled by updating 
>>> that).
>>>
>>> Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for 
>>> IPv4 (mip4)
>>>
>>>
>>>>

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Jun 2006 10:47:09 -0700

It certainly makes sense to have the MIP4 WG do a MIP4 extension, my 
question is still: does it need to be in a separate document?

            jak

PS: I hate to sound overly ideological, but IETF really does need to 
consider the usability impact of its antiquated documentation technology 
when making decisions about what material goes into what documents.

----- Original Message ----- 
From: "Pete McCann" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; "Mobile IPv6 Mailing List" 
<[email-masked]>; "Henrik Levkowetz" <[email-masked]>
Sent: Thursday, June 15, 2006 10:25 AM
Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 
(mip4)

>> document? Wouldn't it be more practical from an implementation standpoint 
>> to have the transition mechanism documented in one place, so implementors 
>> didn't have to go paging through the RFC Web site to track down all the 
>> bits and pieces they need to make it work?
>>
>>            jak
>>
>>>> the draft that is currently being worked on in the MIP6 WG? If the only 
>>>> work involves having someone from the MIP4 WG review the draft, then is 
>>>> there really need for a new charter item? On the other hand, if there 
>>>> is need for another document describing the interaction between the 
>>>> MIP6 transition work and MIP4, then maybe there is need for a new 
>>>> charter item (but if that is true, I'd say it's a flaw in the MIP6 
>>>> transition document, and it should be handled by updating that).
>>>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 15 Jun 2006 11:18:00 -0700

> works on related issues I wanted to point you to this update.

I am opposed to this. I had expressed concerns on the
MIP4 mailing list and there was a long discussion after
that. here is the link to that thread.
http://www1.ietf.org/mail-archive/web/mip4/current/msg01763.html

IMHO, it will be good to get more opinions (non-MIPv4
folks especially) on this.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Jun 2006 20:31:20 +0200

>  question is still: does it need to be in a separate document?

In what would a common document be different than just using MIP6 3775
and MIP4 3344?  If v4 access then use MIP6 over the MIP4 MN-HA tunnel.
If v6 access then use MIP4 over the MIP6 MN-HA tunnel.

IMHO the current DS-MIPv6 proposal already does much more than needed
(tries to offer IPv4 continuous sessions, when it should try to only
offer IPv6 continuous sessions) and unnecessarily puts a stringent
requirement on HA (run both IPv4 and IPv6).

So I'd rather favour splitting the DS-MIPv6 document, _and_ have a
separate DS-MIPv4 document.  Sounds as much work, I agree, but simpler
problems may be easier to address.

Alex

>  consider the usability impact of its antiquated documentation 
> technology when making decisions about what material goes into what 
> documents.
> 
> To: "James Kempf" <[email-masked]> Cc: "Jari Arkko" 
> <[email-masked]>; "Mobile IPv6 Mailing List" <[email-masked]>;
>  "Henrik Levkowetz" <[email-masked]> Sent: Thursday, June 15, 
> 2006 10:25 AM Subject: Re: [Mip6] FW: Internal WG Review: Recharter 
> of Mobility for IPv4 (mip4)
> 
> 
>>> Is there some reason why that couldn't be included in the 
>>> transition document? Wouldn't it be more practical from an 
>>> implementation standpoint to have the transition mechanism 
>>> documented in one place, so implementors didn't have to go paging
>>>  through the RFC Web site to track down all the bits and pieces 
>>> they need to make it work?
>>> 
>>> jak
>>> 
>>> ----- Original Message ----- From: "Pete McCann" 
>>> <[email-masked]> To: "James Kempf" <[email-masked]> 
>>> Cc: "Jari Arkko" <[email-masked]>; "Mobile IPv6 Mailing 
>>> List" <[email-masked]>; "Henrik Levkowetz" <[email-masked]> 
>>> Sent: Thursday, June 15, 2006 10:14 AM Subject: Re: [Mip6] FW: 
>>> Internal WG Review: Recharter of Mobility for IPv4 (mip4)
>>> 
>>> 
>>>> The proposal is to do a MIP4 extension for handling IPv6 
>>>> addresses. This is distinct from the MIP6 work item which is to
>>>>  extend MIP6 to handle v4 addresses.
>>>> 
>>>> -Pete
>>>> 
>>>> James Kempf wrote:
>>>>> So I'm wondering if there is any work to be done here in 
>>>>> addition to the draft that is currently being worked on in 
>>>>> the MIP6 WG? If the only work involves having someone from 
>>>>> the MIP4 WG review the draft, then is there really need for a
>>>>>  new charter item? On the other hand, if there is need for 
>>>>> another document describing the interaction between the MIP6
>>>>>  transition work and MIP4, then maybe there is need for a new
>>>>>  charter item (but if that is true, I'd say it's a flaw in
>>>>> the MIP6 transition document, and it should be handled by 
>>>>> updating that).
>>>>> 
>>>>> ----- Original Message ----- From: "Jari Arkko" 
>>>>> <[email-masked]> To: "Mobile IPv6 Mailing List" 
>>>>> <[email-masked]> Cc: "Peter McCann" <[email-masked]>; 
>>>>> "Henrik Levkowetz" <[email-masked]> Sent: Thursday, 
>>>>> June 15, 2006 7:49 AM Subject: [Mip6] FW: Internal WG Review:
>>>>>  Recharter of Mobility for IPv4 (mip4)
>>>>> 
>>>>> 
>>>>>> 
>>>>>> FYI -- MIP4 wants to recharter to include work on dual 
>>>>>> stack Mobile IPv4 support (item 10 below). Given that MIP6
>>>>>>  also works on related issues I wanted to point you to this
>>>>>>  update. Comments welcome.
>>>>>> 
>>>>>> --Jari
>>>>>> 
>>>>>> IESG Secretary wrote:
>>>>>> 
>>>>>>> A new charter for the Mobility for IPv4 (mip4) working 
>>>>>>> group in the Internet Area of the IETF is being 
>>>>>>> considered.  The draft charter is provided below for your
>>>>>>>  review and comment.
>>>>>>> 
>>>>>>> Review time is one week.
>>>>>>> 
>>>>>>> The IETF Secretariat
>>>>>>> 
>>>>>>> +++
>>>>>>> 
>>>>>>> Mobility for IPv4 (mip4) ==========================
>>>>>>> 
>>>>>>> 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
>>>>>>> 
>>>>>>> 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
>>>>>>> 2. Work items that are pending from the previous Mobile 
>>>>>>> IP WG, which will be completed by the MIP4 WG, are:
>>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> 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.
>>>>>>>  The basic idea is to include an IPv6 address in the 
>>>>>>> Mobile IPv4 signaling messages. The working group will 
>>>>>>> take on and complete one proposal for IPv6 over Mobile 
>>>>>>> IPv4.
>>>>>>> 
>>>>>>> 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 Mar 2006 MIPv4 RADIUS 
>>>>>>> Extensions Requirements to RADEXT WG for comment Apr 2006
>>>>>>>  Revised rfc2794bis (NAI extension) (Draft Std.) to the 
>>>>>>> IESG May 2006 MIPv4 Mobike interaction (BCP) to the IESG 
>>>>>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG May 2006
>>>>>>> RADIUS Extensions for MIPv4 to the RADEXT WG for comment
>>>>>>> Jun 2006 Revised MIPv4 specification to IESG for Draft
>>>>>>> Std. Jun 2006 Generic Strings for MIPv4 (Proposed Std.)
>>>>>>> to the IESG 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 Dec 2006
>>>>>>>  Revised MIB for MIPv4 (Proposed Std.) to IESG Dec 2006 
>>>>>>> Dual-stack MIPv4 (Proposed Std.) to IESG
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________ Mip6 
>>>>>> mailing list [email-masked] 
> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Jun 2006 20:46:15 +0200

Hi James,

> handled by updating that).

This work item covers the ability of MIPv4 to carry IPv6 packets, and does
not overlap with the MIP6 work of giving MIPv6 the ability to carry IPv4
packets and run over IPv4 access networks.

Regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Jun 2006 20:49:40 +0200

Hi James,

> and pieces they need to make it work?

Since this work is only relevant for MNs and mobility agents that are
running MIPv4, I think it makes a fair amount of sense to place it in
a document which simply describes it as an MIPv4 option - which is what
it is...

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Jun 2006 21:03:30 +0200

Hi James,

> when making decisions about what material goes into what documents.

More and more people these days are browsing documents under
http://tools.ietf.org/html/ and thereby gets HTML links between
documents - take for instance the MIPv6 or MIPv4 specifications,
and follow links to your heart's desire:

  http://tools.ietf.org/html/rfc3775

  http://tools.ietf.org/html/rfc3344

or go to the htmlized version of the RFC index and click on:

  http://tools.ietf.org/rfc/index

(I've had a factor of 10 increase of traffic to the tools.ietf.org
 servers over the last ~ 9 months...)

This works best if people use references like this: "RFC 3344 [1]",
which lets you go directly to the RFC, but also with just numbered
or symbolic references without the RFC spelled out it lets you
click to the referenced document via the reference section.

Since I'm convinced that this can be further improved, and will
be increasingly well used, I think it would be very wrong to
group things that aren't particularly closely related into one
mega-document when they would be better described, and more easily
worked at, as separate documents.

Regards,

	Henrik

>>>>> <[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Jun 2006 21:36:26 +0200

Henrik Levkowetz wrote:
>> So I'm wondering if there is any work to be done here in addition 
>> to the draft that is currently being worked on in the MIP6 WG? If 
>> the only work involves having someone from the MIP4 WG review the 
>> draft, then is there really need for a new charter item? On the 
>> other hand, if there is need for another document describing the 
>> interaction between the MIP6 transition work and MIP4, then maybe 
>> there is need for a new charter item (but if that is true, I'd say 
>> it's a flaw in the MIP6 transition document, and it should be 
> This work item covers the ability of MIPv4 to carry IPv6 packets, and
>  does not overlap with the MIP6 work of giving MIPv6 the ability to 
> carry IPv4 packets and run over IPv4 access networks.

Right it doesn't overlap with the MIP6 _particular_ work of giving MIPv6
the ability to carry IPv4 packets and run over IPv4 access networks,
which is not all DS-MIPv6.

But DS-MIPv4 seems to overlap with the DS-MIPv6 characteristic whereby
DS-MIPv6 does proxy ARP for a permanent IPv4 home address and whereby
DS-MIPv6 offers reachability at a permanent IPv4 home address.  If
DS-MIPv6 only cared about IPv6 permanent home addresses (not IPv4) then
there would be more place for DS-MIPv4.

For v4-v6 transition one would have two possibilities: either use
DS-MIPv6 (if the original stack is MIP6) or use DS-MIPv4 (if the
original stack is MIP4).  As two separate specs (DS-MIP4, DS-MIP6) I
don't see anything wrong with that.

A common spec (containing both DS-MIPv4 and DS-MIPv6 concepts) would
have to remove some text from the current DS-MIPv6 text.  And it risks
becoming a bigger spec than MIP4+MIP6 combined, I'm afraid.

On the topic of tools.ietf.org, I'm a fan of many of the new tools and
thanks for them.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Jun 2006 12:45:15 -0700

>worked at, as separate documents.

If two things aren't part of the same set of mechanisms an implementor would 
need in order to implement a protocol or system, then of course they 
shouldn't be in the same document.

But in the past, there has been a tendency to want to break protocol 
definitions apart, for better modularity. For example, breaking out route 
optimization from the MIP6 document which is currently in the charter (so 
this discussion is not completely irrelevant to the list, which is why I'm 
posting it here too). While I am in principle in favor of this, without some 
kind of hypertext linking, this imposes a higher cognitive burden on the 
implementor. They may not even know where all the pieces are.

I'm certainly glad to see the tools.ietf.org hypertext linking being used, 
but I don't think it is really a solution until it becomes the default way 
that RFCs are available online, that is, it is linked from the official IETF 
RFC Web page. It also is lacking an important aspect of modern documentation 
technology - the ability to do high quality graphics. As protocols become 
more complex, graphical representations become more important for complete 
understanding. ASCII art just doesn't cut it anymore, despite emacs macros 
and all the other tools people have proposed. Neither does being able to 
post an alternative postscript version.

            jak

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Jun 2006 22:14:22 +0200

Hi James,

> shouldn't be in the same document.

Ok.

> implementor. They may not even know where all the pieces are.

Agreed.

> RFC Web page.

Also agreed.

> It also is lacking an important aspect of modern documentation 

I mostly agree, but maybe don't feel as strongly about this as you do.

Regards,

	Henrik

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 15 Jun 2006 18:15:28 -0500

Henrik,

In the DS-MIP6 case the reasoning for the work has been that IPv6 native
access is not expected to be ubiquitous and hence given that the host is DS
and access is IPv4, there is a need to enable MIP6 continuity while being
attached to a v4 network. The ability to carry IPv4 within the MIP6 session
is to enable applications and services that are v4 based on the hosts and is
applicable in the scenario when the host is connected to a native v6 access
only (which I guess we believe will be the situation at some point in the
future). So I believe there is a good reason to do this for MIP6.

In the case of IPv4 hosts which are DS and MIP4 enabled, I do not think that
you have to contend with the fact that you have to deal with a v6 access
only. Secondly if the v6 stack on the host needs to connect to a v6 router,
it could just as well use a standard transition mechanism. So having IPv6
packets carried over a MIP4 session IMO is not really a critical need. If
there is a belief that a MIP4 based transition mechanism for IPv6 is needed,
then fine. I think that would be the only requirement for such a solution.

-Raj

---

From: Tom Wan <[email-masked]>
Date: Fri, 16 Jun 2006 16:01:32 +0800

I think the current draft in the WG can solve some problems, but it can not
solve all problems.
The current assumptions require that all HA and MN must have an stable ipv4
address at home network.This is reasonable in some scenarios.
But there are some other scenarios. In these scenarios home network does not
support  ipv4 protocol.It is reasonable too.
In some countries, ipv4 address is a scarce resource, so it may be
impossible for every HA to assign a stable ipv4 address to every MN.
In these scenarios, current solution does not work.
So I think there may be some additional work in the v4 traversal field in
the mip6 WG. solutions on these scenarios can be a complementarity to the
dsmip6 protocol which is now the work in the design team.

How do you think my draft on the other DS scenarios? I think it is
different work from the design team and  maybe my solution can be a 
complementarity to the
dsmip6 protocol. The two solutions will not contradict with each other
because their assumptions are different.

On the topic whether the mip4 WG should work on ds solution, I have no idea
now.

BR
Tom

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Jun 2006 10:50:49 +0200

Hi Raj,

Agreed.

> only.

We're not proposing that.

> Secondly if the v6 stack on the host needs to connect to a v6 router,
> it could just as well use a standard transition mechanism.

Using which IP mobility support?

> So having IPv6
> packets carried over a MIP4 session IMO is not really a critical need.

If you by saying this are proposing that a DS node with MIP4 should
provide mobility support for IPv4 sessions, but not for IPv6 sessions,
I disagree strongly.

If MIP4 is the mobility protocol available on the DS node, it should
provide transport for both IPv4 and IPv6, without prejudice.

> If

Couching this in terms of 'transition mechanisms' occludes the simplicity
of the issue.  MIPv4 should provide transport - i.e., mobility support - for
both IPv4 and IPv6 traffic.

Regards,

	Henrik

---

From: Tom Wan <[email-masked]>
Date: Fri, 16 Jun 2006 17:32:27 +0800

Henrik wrote:

==>
In some scenarios,I agree.
In other scenarios, I'd like to add one opinion that sometimes one protocol 
will have to be over the other.
So I think it is up to the scenarios.

BR
Tom

----- Original Message ----- 
From: "Henrik Levkowetz" <[email-masked]>
To: "Basavaraj Patil" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; "Peter McCann" 
<[email-masked]>; "James Kempf" <[email-masked]>; "Mobile IPv6 
Mailing List" <[email-masked]>
Sent: Friday, June 16, 2006 4:50 PM
Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for 
IPv4(mip4)

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Jun 2006 18:49:35 +0200

Please allow me to express related points of view.

Basavaraj Patil wrote:
> Henrik,
> 
> In the DS-MIP6 case the reasoning for the work has been that IPv6 
> native access is not expected to be ubiquitous and hence given that 
> the host is DS and access is IPv4, there is a need to enable MIP6 
> continuity while being attached to a v4 network.

I agree.

> The ability to carry IPv4 within the MIP6 session

Not sure whether you think DS-MIPv6 here... I guess so.  DS-MIPv6
carries IPv4 addresses in MIP6 messaging, and MIP6 messages in
IPv4 messages.

> is to enable applications and services that are v4 based on the hosts
> 
This is wrong IMHO.  DS-MIPv6 should only care about IPv6 applications,
not about IPv4 applications.

> and is applicable in the scenario when the host is connected to a 
> native v6 access only (which I guess we believe will be the situation
>  at some point in the future). So I believe there is a good reason to
>  do this for MIP6.

Again, I disagree MIP6 extensions should care about serving IPv4
applications.  They should only care about IPv6 apps, and only when the
access is IPv4.

> In the case of IPv4 hosts which are DS and MIP4 enabled, I do not 
> think that you have to contend with the fact that you have to deal 
> with a v6 access only.

It is very reasonable to believe that IPv6 networks will simultaneously
support IPv4, especially in the access part, and at least in the very
near future.  I share this view.

However, protocol development in IETF may happen such that some
networks risk to be only IPv6, not IPv4.  For example, recently in the
NEMO WG there seemed to be a strong pushback on development of NEMOv4
(simple extensions to Mobile IPv4 to support network mobility).  I.e.
moving networks would be only IPv6 networks.  In this case, a MIPv4 MN
wishing to visit such a network would need IPv6 extensions to MIP4 to be
able to connect to it.

>  it could just as well use a standard transition mechanism.

Completely agree.  Moreover, this applies to DS-MIPv6.  If the host runs
MIP6, connects to an IPv4 access and needs to talk to its IPv6 HA it is
sufficient to use a standard transition mechanism.  That could be the
MIP4 NAT Traversal part, or 6to4 or Teredo or IKE or even STUN.  6to4
can't easily be used behind NAT.  MIP4 NAT Traversal, Teredo, IKE and
STUN can.  All three use UDP encapsulation.  (All three have some issues
with some NATs but that's another point.)

> So having IPv6 packets carried over a MIP4 session IMO is not really
>  a critical need. If there is a belief that a MIP4 based transition 
> mechanism for IPv6 is needed, then fine.

I believe there is a much more critical need for work on MIP4 extensions
to support IPv6 than is for DS-MIPv6.  There are much more deployed MIP4
nodes than MIP6 nodes.  Many deployers are faced with a migration
problem, from IPv4 to IPv6.  Very few lucky have the luxury to start
with a clean slate network and end nodes.

Alex

---

From: Tom Wan <[email-masked]>
Date: Mon, 19 Jun 2006 10:44:51 +0800

> near future.  I share this view.
===>
 I think it is only a wish. I hope IPv6 networks should simultaneously 
support IPv4 too.
But In some conditions, it may be impossible, because many countries have no 
enough
ipv4 addresses. They can not assign every MN an ipv4 home address. So the 
most important
point is that MN may have no stable ipv4 home address.

> not about IPv4 applications.

===>
I'd like to emphasize this point.
I think that the two protocols(ipv4/ipv6) have two usages: one is for 
routing
and the other is for application. The routing usage is mainly implemanted on
routers and the application usage is implemanted on the mobile node.
As mobile ip is a network layer solution, we should focuse on the routing 
usage.

I think the application usage is out of scope of mobile ip. In addition, 
after
we solve the routing problem. application layer usage is not a problem.

>> mechanism for IPv6 is needed, then fine.

===>

Standard transiton mechanism is only one direction. there are two directions 
of solutions.
One is based on the v4/v6 interaction solutions. The other is based on the 
mip4/mip6
protocol. I think mip4/mip6 protocol is enough for v4/v6. If we use NAT/PT 
method,
many folks will criticize it. Currently, few venders dear to use NAT/PT 
solution, it
will cause many problems.  So I think ipv6 over ipv4 is necessary.
In the ipv6 WG, there are two kinds of solutions on the v4/v6 interaction 
topic.
One is based on NAT/PT, the other is based on the tunneling mechanisms.
They both work.

IMO, I think we can consider a solution. The solution is based on tunneling 
mechanism and
it will not do much impact to the mip4/mip6 protocols. This is one 
requirement.

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "Basavaraj Patil" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; "Peter McCann" 
<[email-masked]>; "James Kempf" <[email-masked]>; "Levkowetz" 
<[email-masked]>; "Mobile IPv6 Mailing List" <[email-masked]>
Sent: Sunday, June 18, 2006 12:49 AM
Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for 
IPv4(mip4)

>> access is not expected to be ubiquitous and hence given that the host is 
>> DS and access is IPv4, there is a need to enable MIP6 continuity while 
>> being attached to a v4 network.
>
> I agree.
>
>> and is applicable in the scenario when the host is connected to a native 
>> v6 access only (which I guess we believe will be the situation
>> In the case of IPv4 hosts which are DS and MIP4 enabled, I do not think 
>> that you have to contend with the fact that you have to deal with a v6 
>> access only.
>

---

From: Tom Wan <[email-masked]>
Date: Mon, 19 Jun 2006 11:12:12 +0800

Hi, all:

I think your discussion is related to my drafts:
http://www.ietf.org/internet-drafts/draft-wan-mip6-nemo-dsanalysis-00.txt
http://www.ietf.org/internet-drafts/draft-wan-mip6-nemo-routing-00.txt

I hope you can review and discuss them.

BR
Tom