Subject: [Mip6] review of draft-ietf-mip6-dsmip-problem-00.txt

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Oct 2005 15:16:50 +0300

I reviewed this draft. Overall, its pretty easy to agree
with what is said. My main concern is that the draft is taking a
relatively narrow view into this problem. For instance, its likely that
we need NATs, corporate VPN compatibility, various extra
mobility features developed over the years, etc. as well
as basic mobility. How do we achieve this? And I don't think
the real issue is minor differences in amount of signaling,
even if us researchers and engineers would like to optimize
everything... the real issue is getting a mobility solution
that works, no matter what environment you are in.
I don't mean that we necessarily need to develop everything
right now, but I'd like to see a description of the whole
problem, and some ideas about how we are going about
addressing it.

More comments below:

>    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

I do not think this is just about ineffiency! We have no connectivity
or at least session survivability without some form of interworking
between different mobility mechanisms.

> 2.4. The impossibility of maintaining connectivity
>
>    A final point to consider is that even if both mobility protocols are
>    supported by a mobile node seamless connectivity would not in fact be
>    guarantied since that also depends on the IPv4/IPv6 capabilities of
>    the networks the mobile is visiting i.e.: a dual stack node
>    attempting to connect via a IPv4 only network would not be able to
>    maintain connectivity of its IPv6 applications and vice versa.

This, to me, is the main problem in fact. If you assume you have
v4 and v6 everywhere, why not just use Mobile IPv6? But the
reality is that we'll find ourselves more or less forever locked
in a situation where there are at least some networks that
are v4 only. From a commercial standpoint, we do not want
to deploy technology that only works some of the time, so I think
people are looking for solutions that work in all cases.
And "work" = "works for the user's ongoing sessions", not
just "we can send mobility protocol signaling messages".

>    - it should be possible to create IPv4 extensions to Mobile IPv6 so
>    that a dual stack mobile node can register its IPv4 and IPv6 HoAs to
>    a dual stack Home Agent using MIPv6 signaling only.

>    - it should be possible to create IPv6 extensions to MIPv4 so that a
>    dual stack mobile node can register its IPv4 and IPv6 HoAs to a dual
>    stack Home Agent using MIPv4 signaling only.

>    - it should also be possible to extend MIPv4 and MIPv6 so that a
>    mobile can register a single CoA (IPv4 or IPv6) to which IPv4 and/or
>    IPv6 packets can be diverted to.

Yes. These are all things that we should do, I think.

But this list is also quite short in comparison to what
has been documented elsewhere, e.g., draft-larsson-v6ops-mip-scenarios.
E.g. transition mechanism-based approaches have not been
mentioned.

Also, there's a body of work that relates to various kinds
of additions over the basic protocols. It would be interesting
to understand the bigger picture of how we are going to
use the additional components (RO, fast handovers, various
auth schemes, ...) in a mixed environment.

> 2.2. Operational burdens
>
>    As mentioned earlier, deploying both protocols will require managing
>    both protocols in the mobile node and the home agent. This adds
>    significant operational issues for the network operator. It would
>    certainly require the network operator to have deep knowledge in both
>    protocols. This might add a significant cost for deployment that an
>    operator cannot justify due to the lack of substantial gains.

Duplicate user credentials are a possibility at this time
(e.g. MIPv4 shared secrets, MIP6 auth option, MIPv6 IKE/IPsec
SAs or keys, IKEv2-based EAP credentials, ...). Probably worthwhile to
mention as a separate item.

> 4. References

References to other work in this space might be appropriate.
Can't give you a good list, but I'm sure there are some items
that could be mentioned here. In fact, even the existing references
in the text such as [MIPv4] are not listed here.

--Jari

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

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 13 Oct 2005 16:31:51 -0400

Jari,

It might be a good idea to separate v4 to v6 migration and NAT type
issues from enabling MIP to creating bindings for v4 and v6 HoAs.

The v4 to v6 transition and NAT issue has nothing to do with the version
of the HoA; instead it is purely about how to run a given
protocol/application *over* v4 and v6 based networks as well as over
NATs and other such devices. 

In contrast, the dsmip problem described in the problem statement is
about allowing a single signaling protocol to create and manipulate v4
and v6 HoAs.

What I am arguing is that these as separable/orthogonal problems and it
will be easier to treat them as such. 

Regards
George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Thursday, October 13, 2005 8:17 AM
> To: Mobile IPv6 Mailing List
> Subject: [Mip6] review of draft-ietf-mip6-dsmip-problem-00.txt
> 
> 
> with what is said. My main concern is that the draft is 
> taking a relatively narrow view into this problem. For 
> instance, its likely that we need NATs, corporate VPN 
> compatibility, various extra mobility features developed over 
> the years, etc. as well as basic mobility. How do we achieve 
> this? And I don't think the real issue is minor differences 
> in amount of signaling, even if us researchers and engineers 
> would like to optimize everything... the real issue is 
> getting a mobility solution that works, no matter what 
> environment you are in. I don't mean that we necessarily need 
> to develop everything right now, but I'd like to see a 
> description of the whole problem, and some ideas about how we 
> are going about addressing it.
> 
> More comments below:
> 
> I do not think this is just about ineffiency! We have no 
> connectivity or at least session survivability without some 
> form of interworking between different mobility mechanisms.
> 
> This, to me, is the main problem in fact. If you assume you 
> have v4 and v6 everywhere, why not just use Mobile IPv6? But 
> the reality is that we'll find ourselves more or less forever 
> locked in a situation where there are at least some networks 
> that are v4 only. From a commercial standpoint, we do not 
> want to deploy technology that only works some of the time, 
> so I think people are looking for solutions that work in all 
> cases. And "work" = "works for the user's ongoing sessions", 
> not just "we can send mobility protocol signaling messages".
> 
> E.g. transition mechanism-based approaches have not been mentioned.
> 
> of additions over the basic protocols. It would be 
> interesting to understand the bigger picture of how we are 
> going to use the additional components (RO, fast handovers, 
> various auth schemes, ...) in a mixed environment.
> 
> > 2.2. Operational burdens
> >
> SAs or keys, IKEv2-based EAP credentials, ...). Probably 
> worthwhile to mention as a separate item.
> 
> > 4. References
> 
> that could be mentioned here. In fact, even the existing 
> references in the text such as [MIPv4] are not listed here.
> 
> --Jari
> 
> 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

---

From: [email-masked]
Date: Sun, 16 Oct 2005 16:08:33 +0300

George,

First, I agree that these are separate problems - but are you saying
that they should be addressed seperately in the document, or in separate
documents?  Even if they are split into separate documents, NAT
traversal
will be an issue.  I don't mind if the DSMIP document points to another
document, it will at least need to discuss some operation issues of
running
a dual stack mobile node when a NAT is present.  I'm fine if it just
points
to the NAT traversal document with some operational considerations for
the
dual stack node.

John

>Behalf Of ext Tsirtsis, George
>Sent: 13 October, 2005 23:32
>To: Jari Arkko; Mobile IPv6 Mailing List
>Subject: RE: [Mip6] review of draft-ietf-mip6-dsmip-problem-00.txt
>
>Jari,
>
>It might be a good idea to separate v4 to v6 migration and NAT 
>type issues from enabling MIP to creating bindings for v4 and v6 HoAs.
>
>The v4 to v6 transition and NAT issue has nothing to do with 
>the version of the HoA; instead it is purely about how to run 
>a given protocol/application *over* v4 and v6 based networks 
>as well as over NATs and other such devices. 
>
>In contrast, the dsmip problem described in the problem 
>statement is about allowing a single signaling protocol to 
>create and manipulate v4 and v6 HoAs.
>
>What I am arguing is that these as separable/orthogonal 
>problems and it will be easier to treat them as such. 
>
>
>Regards
>George
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Jari Arkko
>with what is 
>> said. My main concern is that the draft is taking a 
>relatively narrow 
>> view into this problem. For instance, its likely that we need NATs, 
>> corporate VPN compatibility, various extra mobility features 
>developed 
>> over the years, etc. as well as basic mobility. How do we achieve 
>in amount 
>> of signaling, even if us researchers and engineers would like to 
>> optimize everything... the real issue is getting a mobility solution 
>> that works, no matter what environment you are in. I don't mean that 
>> we necessarily need to develop everything right now, but I'd like to 
>> see a description of the whole problem, and some ideas about how we 
>connectivity 
>> This, to me, is the main problem in fact. If you assume you have v4 
>> and v6 everywhere, why not just use Mobile IPv6? But the reality is 
>> that we'll find ourselves more or less forever locked in a situation 
>> where there are at least some networks that are v4 only. From a 
>> commercial standpoint, we do not want to deploy technology that only 
>> works some of the time, so I think people are looking for solutions 
>> that work in all cases. And "work" = "works for the user's ongoing 
>> sessions", not just "we can send mobility protocol signaling 
>> messages".
>> 
>> But this list is also quite short in comparison to what has been 
>> documented elsewhere, e.g., draft-larsson-v6ops-mip-scenarios.
>> Also, there's a body of work that relates to various kinds of 
>> additions over the basic protocols. It would be interesting to 
>> understand the bigger picture of how we are going to use the 
>> additional components (RO, fast handovers, various auth 
>schemes, ...) 
>> in a mixed environment.
>> 
>> > 2.2. Operational burdens
>> >
>(e.g. MIPv4 
>> shared secrets, MIP6 auth option, MIPv6 IKE/IPsec SAs or keys, 
>> IKEv2-based EAP credentials, ...). Probably worthwhile to 
>mention as a 
>> separate item.
>> 
>> > 4. References
>> 
>> Can't give you a good list, but I'm sure there are some items that 
>> could be mentioned here. In fact, even the existing 
>references in the 
>> text such as [MIPv4] are not listed here.
>> 
>> --Jari
>> 
>> 
>This email may contain confidential and privileged material 
>for the sole use  of the intended recipient.  Any review or 
>distribution by others is strictly  prohibited.  If you are 
>not the intended recipient please contact the sender  and 
>delete all copies.

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 17 Oct 2005 09:25:26 -0400

Hi John,

I actually think these are entirely orthogonal issues, in which case
they can be defined in different documents without referring to each
other.....but maybe we should first make sure we are talking about the
same thing.

For example, I am not sure what kind of NAT traversal issue we talking
about here? I do understand, however, the v4 to v6 transition issue
which goes like this:
MIP6 signaling running between an MN and an HA requires that IPv6
connectivity is available between that MN and that HA. If there is no
native IPv6 connectivity available then, we have an IPv4 to IPv6
transition issue; i.e., some form of tunneling or other transition
mechanism is required to provide the IPv6 path between the two entities.
As far as I can tell, this has nothing to do with what kind of HoAs are
handled by MIP6. Do you agree so far?

I am not sure what is the NAT traversal issue though...can anyone
illuminate?

Thanks
George

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, October 16, 2005 9:09 AM
> To: Tsirtsis, George; [email-masked]; [email-masked]
> First, I agree that these are separate problems - but are you 
> saying that they should be addressed seperately in the 
> document, or in separate documents?  Even if they are split 
> into separate documents, NAT traversal will be an issue.  I 
> don't mind if the DSMIP document points to another document, 
> it will at least need to discuss some operation issues of 
> running a dual stack mobile node when a NAT is present.  I'm 
> fine if it just points to the NAT traversal document with 
> some operational considerations for the dual stack node.
> 
> John
>

---

From: [email-masked]
Date: Tue, 18 Oct 2005 08:29:52 +0300

Hi George,
>I actually think these are entirely orthogonal issues, in 
>which case they can be defined in different documents without 
>referring to each other.....but maybe we should first make 
>sure we are talking about the same thing.

Let's say it like this. After re-reading the problem statement, 
NAT is not an issue, as the current document is written.  However,
I think that any dual stack MIP implementation will need to be
considered with NAT traversal, along with the transition issues
youlise below.

>For example, I am not sure what kind of NAT traversal issue we 
>talking about here? I do understand, however, the v4 to v6 
>transition issue which goes like this:
>MIP6 signaling running between an MN and an HA requires that 
>IPv6 connectivity is available between that MN and that HA. If 
>there is no native IPv6 connectivity available then, we have 
>an IPv4 to IPv6 transition issue; i.e., some form of tunneling 
>or other transition mechanism is required to provide the IPv6 
>path between the two entities.
>As far as I can tell, this has nothing to do with what kind of 
>HoAs are handled by MIP6. Do you agree so far?

Agreed - some solutions might optimize things here, but that is
probably not anything needed to be covered in the problem statement.

>I am not sure what is the NAT traversal issue though...can 
>anyone illuminate?

My reasoning is that for any reasonable MIPv4 implementation,
you need to worry about NAT traversal - that is just a fact
of life.  Anyone running a dual stack MIP node will need to worry
about NAT traversal.  

Anyhow, as I mentioned before, as written, the draft doesn't cover
quite cover issues where NAT might impact a solution.  If the WG
is fine with this, then I won't worry about it.

John