Problem Statement: Dual Stack Mobility
draft-ietf-mip6-dsmip-problem-03

[Note]: 'PROTO shepherd is Basavaraj Patil <basavaraj.patil@nokia.com>
NOTE 1: There are significant RFC Editor notes!
NOTE 2: Earlier, Brian proposed changes which the authors now accept. No new revision.' added by Jari Arkko

[Ballot comment]
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.

[Ballot comment]
[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.

[Ballot comment]
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.

[Note]: 'PROTO shepherd is Basavaraj Patil <basavaraj.patil@nokia.com>
NOTE 1: There are significant RFC Editor notes!
NOTE 2: Bringing back to agenda to resolve discusses and get more votes' added by Jari Arkko

[Ballot comment]
Section 1., paragraph 1:
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].

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

[Ballot discuss]
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

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

NEW
  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:

and
OLD
  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.

NEW
  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.

[Ballot discuss]
The title page heading says:
  >
  > Intended status: Standards Track
  >
  This document is being considered for Informational.  A note to the
  RFC Editor is a fine fix.

  In the write-up, the things listed in the IESG Note belong in a Note
  to the RFC Editor.

[Ballot discuss]
The title page heading says:
  >
  > Intended status: Standards Track
  >
  This document is being considered for Informational.  A note to the
  RFC Editor is a fine fix.

  In the write-up, the things listed in the IESG Note belong in a
  Note to the RFC Editor notes.

[Ballot comment]
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.

AD review follow up sent to the mip4 and mpi6 list on Feb 16th, 2007. The new version does not address everything it needed to, but the rest is handled with RFC Editor notes, assuming the WG agrees.

AD review part 2:

Editorial:

Overall, this document needs an editorial
cleanup and better formatting. Random
linefeeds in particular are making it hard
to read.
> 1. Terminology
>   
>    In addition to [KEYWORDS], this draft uses the following terms as
You do not use any keywords.
>  * The document seems to lack an IANA Considerations section.
This is optional, but I normally insert a "There are no IANA
considerations." text just to make it clear that the IANA does
not have to read the entire document.
>  * The document seems to lack separate sections for Informative/Normative
>    References.
This is needed.
>   
>    Checking conformance with RFC 3978/3979 boilerplate...
>
>  * The document seems to lack an RFC 3978 Section 5.5 Disclaimer -- however,
>    there's a paragraph with a matching beginning. Boilerplate error?
>  * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure
>    Acknowledgement -- however, there's a paragraph with a matching beginning.
>    Boilerplate error?
>  * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure
>    Acknowledgement -- however, there's a paragraph with a matching beginning.
>    Boilerplate error?
>
>  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>  * The document seems to lack a 1id_guidelines paragraph about
>    Internet-Drafts being working documents -- however, there's a paragraph
>    with a matching beginning. Boilerplate error?
>  * The document seems to lack a 1id_guidelines paragraph about 6 months
>    document validity -- however, there's a paragraph with a matching
>    beginning. Boilerplate error?
>  * The document seems to lack a 1id_guidelines paragraph about the list of
>    current Internet-Drafts -- however, there's a paragraph with a matching
>    beginning. Boilerplate error?
>  - The page length should not exceed 58 lines per page, but there was 7
>    longer pages, the longest (page 6) being 68 lines
>  - It seems as if not all pages are separated by form feeds - found 0 form
>    feeds but 7 pages
Hesham, please, move to xml2rfc. Its so much easier
for everyone. You don't need any software, btw,
you can convert to text at xml.resource.org.
>  Miscellaneous warnings:
>  - The "Author's Address" (or "Authors' Addresses") section title is
>    misspelled.
Please fix.

>    We argue that all of the above will hinder the deployment of Mobile
>    IPv6 as well as any dual stack solution in a mobile environment. We
I would suggest saying "makes harder to deploy ..." instead
of "will hinder". This could be just a language issue, but
my understanding is that "hinder" can be interpreted
as "block" -- and I'm not sure I would agree with such
a strong statement.
>    clearly inefficient since it requires:
s/clearly// (better style)

> Each of these systems
>      requiring their own sets of optimizations that may include
>      hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast
>      Handoffs for Mobile IPv4, mechanisms that are currently in
>      development in the IETF.
The list seems a bit out of place, and somewhat arbitrary.
I would suggest s/optimizations .*/optimizations./

> Deploying both in a dual stack mobile node
> introduces a number of inefficiencies.
s/inefficiencies/problems/ (a pure mip6+mip4 solution
would block either v4 or v6 communications, depending
on which type of access network you are in)
> The draft
>    also hints on how the current [MIPv4] and [MIPv6] protocols could be
>    extended so that they can support mobility management for a dual
>    stack node.
References in abstract.

Also, I'm not sure you really talk or should talk about the "how"
part. Suggested rewording: "The draft also discusses requirements
for the Mobile IPv4 and Mobile IPv6 protocols so that they can
support ..."

> 2. Introduction and motivation
This section focuses on the argument that we need
to have one mobility protocol handle both protocol
versions. I would suggest the addition of the basic
connectivity problem explanation before bullet
list.
> 3.4. The impossibility of maintaining IP connectivity
I would start with this in Section 3.

AD review part 1:

Technical:
>    - Double the amount of configuration in the mobile node and the home
>
>      agent (e.g., security associations).
... and later ...
>    In addition, deploying both protocols will require duplication of
>    security credentials on mobile nodes and home agents. This includes,
>    IPsec security associations, keying material, and new authentication
>    protocols for Mobile IPv6, in addition to the security credentials
>    and associations required by Mobile IPv4. Such duplication is again
>    significant with no gain to the operator or the mobile node.

Is this true under all circumstances? For instance,
is it true if one uses RFC 4285 or EAP for Mobile IPv6
authentication?

Depending on the answer, please reword
and add the necessary explanations.
>    - Local network optimizations for handovers will also need to be
>      duplicated.
Only insofar as  they are bound to the mobility
protocol. There are a large number of optimizations
(L2 pre-auth etc) that deal with other aspects of the
handover problem and do not impact what happens
at IP or IP mobility layers.

Please reword.
> 3.1. Implementation burdens
>   
>    As mentioned above, a node that is IPv4 and IPv6 capable must also be
>
>    MIPv4 and MIPv6 capable to roam within the Internet. Clearly this
>    will add implementation efforts, which, we argue, are not necessary.
>
>   
>    In addition to the implementation efforts, some vendors may not
>    support both protocols in either mobile nodes or home agents.
>    Although this is more of a commercial issue, it does affect the
>    large-scale deployment of mobile devices on the Internet.
>   
I'm not sure this section reflects the complete
picture. In a situation where host vendors
are independent of those who deploy the
mobility infrastructure, for instance, its
not clear that there is any reduction in
implementation effort.

Please reword for better balance.

>  Checking nits according to http://www.ietf.org/ID-Checklist.html:
>  * The document seems to lack a Security Considerations section.

This is needed (not just the section but the
content as well).

>    Further work in this area, possibly independent of Mobile IP, may
>    also be of interest to some parties in which case it should be dealt
>    with separately from the incremental Mobile IP based changes.
This statement seems out of place. Or at least I could
not think of what specific further work you were thinking
of.
> 3.0 Problem description
I am missing an explanation of why various existing,
non-mobility related transition mechanisms are insufficient
for solving the issues listed in this document. I believe
they are insufficient, but the document needs to explain
why.

Please add the explanation.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Basavaraj Patil. I have reviewed the I-D and believe it is ready to be
forwarded to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes. A joint WG LC (MIP6/4) was done for this I-D since the problem
statement is applicable to both. I do not have any concerns about the
depth or breadth of the reviews. I believe it has been reviewed
sufficiently.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The document has had adequate review and I do not believe further or
extended reviews are necessary.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

I do not have any concerns in moving forward with this I-D in the
standards process.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Solid WG consensus exists behind this document. Both the MIP6 and MIP4
WGs agree with this document contents.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

There are a few I-D nits abd boiler-plate problems. These will be
addressed following the AD comments and a subsequent revision.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

No. This is on an Informational track and is a problem statement
draft. There are some corrections needed to the references
section. The MIP6 reference is incorrect. These will be addressed in
the next revision as part of either addressing the AD comments or
during the RFC ed. process.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with
the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?

This is a problem statement I-D. No specific protocol extensions or
IANA requirements exist.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Does not apply. This is a problem statement I-D.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This draft discusses the issues associated with mobility management
for dual stack mobile nodes. Currently, two mobility management
protocols are defined for IPv4 and IPv6. Deploying both in a dual
stack mobile node introduces a number of inefficiencies. Deployment
and operational issues motivate the use of a single mobility
management protocol. This draft discusses such motivations. The draft
also hints on how the current MIP4 and MIP6 protocols could be
extended so that they can support mobility management for a dual
stack node.


Working Group Summary

This I-D was initially produced as a problem statement for the MIP6
WG. However subsequently it was noted that it applied to MIP4 as
well. Hence the I-D is now considered as being applicable to the MIP4
and MIP6 WGs. There is consensus behind this document and the need to
address the problem.

Document Quality

The I-D is a problem statement document. The quality of the document
is good.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director?

Document shepherd: Basavaraj Patil
Responsible AD: Jari Arkko