Problem Statement: Dual Stack Mobility
RFC 4977

Note: This ballot was opened for revision 03 and is now closed.

(Brian Carpenter) Discuss

Discuss (2007-02-22)
The draft is very clear; the problem description is excellent
and long overdue. However, I have serious trouble with the
recommendation that we should simultaneously "create IPv4
extensions to Mobile IPv6" and "create IPv6 extensions to
Mobile IPv4".

This might console vendors or SPs who've invested heavily 
in one or the other, but it causes severe problems for roaming
users, whose need is a single Mobile IP, period. Roaming 
users may not be always bound to the same home site and 
service provider (that's called consumer choice). If a roaming 
user wants to choose between multiple SPs, and wants dual stack
service from all of them, the mobile host will in any case have
to support both varieties of dual stack MIP, and will have to
choose automagically between them. So the effect of this
dual recommendation is an increase in complexity and/or a
reduction in interoperability.

I didn't understand when MIP4 was rechartered that we
were in effect approving this dual approach in the words:
"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."

I think the choice of direction here is for the IETF, not
for a single WG or the IESG. I think we should not proceed 
on this path without a real debate, to reach consensus on one 
interoperable direction.

As far as this draft goes, if the recommendation to do
both is the consensus of the MIP6 WG, I'd be satisfied with
a text change in section 5 that would make it clear
that this is not an IETF consensus. For example

   In order to allow for a gradual transition based on current standards
   and deployment, the following work areas seem to be reasonable:

   The Mobile IPv6 Working Group has reached the view that to allow 
   for a gradual transition based on current standards and deployment, 
   the following work areas would be reasonable:

   Following the steps listed above, a vendor can choose to support one
   mobility management protocol while avoiding the incompatibility and
   inefficiency problems listed in this document.  Similarly, operators
   can decide to continue using one mobility management protocol while
   addressing the transition scenarios that a mobile node is likely to
   face when roaming within the Internet.

   If the IETF chooses to pursue all these paths, a vendor could choose 
   to support one mobility management protocol while avoiding the 
   incompatibility and inefficiency problems listed in this document.
   Similarly, operators could decide to continue using one mobility
   management protocol throughout the period of IPv4 and IPv6 coexistence.
   However, a mobile node would be forced to choose one approach
   or the other, or nevertheless to install both and use one or
   the other according to circumstances.

(Jari Arkko) Yes

(Ron Bonica) No Objection

(Lisa Dusseault) No Objection

Lars Eggert No Objection

Comment (2007-02-22)
No email
send info
Section 1., paragraph 1:
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    document are to be interpreted as described in [RFC2119].

  Document doesn't use any RFC2119 terms, remove this section and the
  reference to 2119.

(Sam Hartman) No Objection

Comment (2007-06-06)
No email
send info
This is a fairly good problem statement.  However I'm not sure it had
the desired effect at least for me.  I find this document to be a
compelling argument that the complexity of solving this problem is too
high and that we should not do the work, or at least not all the work.
I definitely think the complexity of specifying both IPV6 support for
MIP4 and V4 support for MIP6 is unjustified.  Pick one; in particular
add V4 support for MIP6 but not the other direction.

Note that without performing the tasks described in the IESG note for
RFC 4285 (the mip6 auth protocol), it would be entirely inappropriate
to propose a mechanism to use MIP4 credentials with MIP6.  Also, note
that the current chartered item on the MIP6 charter related to auth
protocol does not propose to do this work.

(Russ Housley) (was Discuss) No Objection

Comment (2007-02-21)
No email
send info
  Section 4.1 Title: s/impossibility/Impossibility/

  Please remove section 8 prior to publication as an RFC.

(Cullen Jennings) No Objection

Comment (2007-02-20)
No email
send info
The draft says the intended status is Standards Track but it should be Informational.

(David Kessens) No Objection

(Chris Newman) No Objection

(Tim Polk) No Objection

Comment (2007-06-06)
No email
send info
[Note: While similar in content to my DISCUSS on nemo-mobility, this is a COMMENT based on
the document's orientation towards migration from IPv4 to IPv6.  The issues listed are more
serious when the multi-homed system is connected to at least one private network.]

The security considerations section indicates that new security considerations are not
introduced because this is a problem statement.  However, there are issues specific to
multihomed systems especially when one of the networks is private.  While not the
focus of this specification, dual stacks could be employed in that fashion.

In that case, multihomed systems that support packet forwarding are attractive targets for
attackers, since they provide can access to other systems and networks that are not
normally accessible.  Even where packet forwarding is disabled, an attacker might attempt to
compromise a system specifically to enable packet forwarding and gain access to normally
inaccessible systems.

(Dan Romascanu) No Objection

Comment (2007-02-21)
No email
send info
1. It looks like the RFC Editor notes were mistakenly mis-placed in the IESG notes in the write-up.

2. It would be worth mentioning in sections 3 and 4.3 that it is not only the mobility management costs that are considerably increased in complexity by supporting both MIPv4 and MIPv6 capable but practically all management aspects and many of the control and management protocols and applications are also duplicated.

(Mark Townsley) No Objection

(David Ward) No Objection

(Magnus Westerlund) No Objection

(Ross Callon) Abstain

Comment (2007-06-06)
No email
send info
First of all, the document says that it is standards track, but the ID tracker says that this is informational. My Abstain is based on this being informational, and will change to a Discuss if this is in fact standards track. 

Even assuming that the tracker is correct and this is informational, I am still somewhat torn between "Abstain" and "Discuss", but chose to go to Abstain because I don't think that there is any change to the document that would change my vote other than discarding the main premise of the document and replacing it with a different document.  

My most fundamental problem with this document is that it seems to ignore the very considerable complexity that would be needed to create a mobility management protocol that would work with both IPv4 and IPv6. For example, creating such a protocol would tie IPv4 and IPv6 mobility together. Any change to one would effect the other. It would also need to deal with the fact that IPv4 topology and IPv6 topology may be different in some cases. 

While this won't effect my vote, there is one section that might benefit from clarification. Specifically:

   4.1.  The impossibility of Maintaining IP Connectivity

   Even if a mobile node is both MIPv4 and MIPv6 capable, connectivity
   across different networks would not in fact be guaranteed since that
   also depends on the IPv4/IPv6 capabilities of the networks the mobile
   is visiting; i.e., a node attempting to connect via a IPv4 only
   network would not be able to maintain connectivity of its IPv6
   applications and vice versa.  This is potentially the most serious
   problem discussed in this document.

Are you referring here to the possibility that a dual stack capable node, that is from an IPv4 only part of the Internet, might be visiting an IPv6 only part of the Internet (or vice versa)? If this is what you mean then this section could be clarified. To me this is the only valid situation that is discussed in the document that might justify work in this area (since IPv4-only and IPv6-only parts of the Internet are a real possibility, as are dual stack mobile hosts). However, this seems to be closely related to past IPv6 transition work that should be taken into consideration (some subset of which ran into issues). 

There are a number of statements in the draft that I think are either confusing or wrong. As an example:

   A node that is both IPv4 and IPv6 capable can use Mobile IPv4 for its
   IPv4 stack and Mobile IPv6 for its IPv6 stack so that it can move
   between IPv4 and IPv6 subnets.  While this is possible, it does not
   ensure connectivity since that also depends on the IP version support
   of the network accessed. 

How does this make any sense? If you support both mobile IPv4, and mobile IPv6, and you are moving, then you will have connectivity as long as *either* IPv4 or IPv6 (or both) are working in the network that you move to. If neither works, then what approach are you proposing that would work? I am assuming that this is referring to the idea of using one version of IP to tunnel to a part of the network that uses the other version of IP. 

   Supporting Mobile IPv4 and Mobile IPv6 is
   also more inefficient since it requires:
      - Network Administrators to run and maintain two sets of mobility
      management systems on the same network.  Each of these systems
      requiring their own set of optimizations.

So, if you define a new mobility protocol that supports both IPv4
and IPv6, then you have three protocols to support: one for IPv4, one for IPv6, and a third one that supports both. Is it realistic to get rid of the other two existing mobility approaches? I would be surprised if it is. 

In section 4.2, implementation burdens, it appears to me that you are proposing a third approach that vendors need to support, **in addition** to the first two. This just makes it more complex (particularly if some parts of the Internet support one, and some support another, so that mobile hosts need to try all possible methods in the hope of finding one that works in whatever part of the Internet the system is in). 

In section 5 (conclusions): 

   Given that Mobile IPv4 is currently deployed and Mobile IPv6
   is expected to be deployed, there is a need for gradual transition
   from IPv4 mobility management to IPv6.  Running both protocols
   simultaneously is inefficient and has the problems described above.

But, having one protocol for both IPv4 and IPv6 means that the two protocols are permanently tied to each other, and that any change to mobility for one is tied to mobility for the other.