Thanks for your comments on our draft!
First, let me say a few words about the scope of the draft. The purpose
of this draft is to provide an overview of (a) possible network and
handoff scenarios; (b) possible deployment cases; and (c) possible
solutions. In this draft, we do not state which deployment cases are
the most probable ones - we just list the possibilities. The intention
is to lay out the field, so that later on, more specific problem
statements and solution proposals can be made, referring to subsets of
the scenarios described in this draft.
Do you have any comments on this approach?
Answers to some of your comments inline.
Pekka Savola wrote:
comments on draft-larsson-v6ops-mip-scenarios-00.txt
See above. More deployment-specific problem statements can be made
later, but that's not really within the scope of this draft.
- you raise a number of (potentials) scenarios by
possibilities. I think it would be useful to try to
describe, e.g., using a
paragraph or two each, the practical use case for each
scenario if one
exists, deployments which are planned or exist, etc.
-- just as a means for
us to try to identify which are the *MOST* relevant
scenarios which must be
See above. In this draft, we do not make statements on whether
different deployment scenarios are good or not - we simply list
- there should probably be some form of problem
why dual MIP protocols is not a good thing. In
each scenario, one might
also consider whether connection survivability is
required in that
Ok... I'm not sure I fully understand what you mean by "type of access
technology". Could you please elaborate on this?
- it probably needs to be evaluated whether it's
assumed that particular
type of access technology (and the resulting tunneling
method) must be
usable everywhere, or just in particular operator's
networks. I.e., "where can the user roam, and still
expect this to work?"
Different solutions have different assumptions on
Sure, the latency depends on the length of the roundtrip as well as the
number of roundtrips. We have not made any assumption on the length of
the roundtrips for wireless links though.
The issue of handoff latency would be
especially important in cases
where Mobile IP provides mobility for real-time
Voice over IP calls. In these cases, an absolute
signaling roundtrips is required at each handoff.
Also, when running
real-time applications, a mobile node cannot
afford to await timeouts
in deciding which mobility signaling mechanism to
use when arriving
at a new access network.
==> it's worth mentioning the unstated
assumption here is that wireless
links being considered here have very long roundtrips
seconds) that it is actually *this* what causes the
problems, not as such
the number of roundtrips..
As MIPv4 does not run over IPv6, and MIPv6 does not run over IPv4, the
assumption is that the MN runs MIPv4 when in an IPv4 network and MIPv6
when in an IPv6 network.
o A solution for deployment case III
(MIPv4-MIPv6) needs to handle
network scenarios 1-2, 7-8 in Table 1 and 9-10
in Table 2. The
handoff scenarios listed in Tables 3 and 4 are
applicable to this type of solution. As the
aim is to address
MIPv4-MIPv6 interworking, we may assume that
MIPv4 and MIPv6 run
in parallel on the MN and the HA, and that the
MN will be able to
shift MIP version during a handoff,
accommodating to the IP
version of its current access network. For
this to work, the MIP
stack in the MN also needs to provide the
transport for both IPv4 and IPv6 sockets.
==> "run in parallel" -- does that mean that
only one version is used at a
time (as a means of transitioning from X to Y -- some
UEs might implement
both, but just one both), or that both are used?
We did not consider address assignment within the scope of this draft.
The only issue I can think of would be the case of an MIPv4 FA. We
could elaborate on that. Was that what you had in mind?
A solution of this kind consists of two parts:
1. Enhance MIPv4 to provide support for tunneling
MIPv4 packets over
IPv6 transports. This solves scenario 5 in
addition to 1, and
scenario 6 if combined with the enhancement
2. Enhance MIPv4 to carry IPv6 payloads. This
solves scenario 2,
and scenario 6 if combined with the
A solution of this kind consists of two parts:
1. Enhance MIPv6 to provide support for tunneling
MIPv6 packets over
IPv4 transports. This solves scenario 4 in
addition to 8, and
scenario 3 if combined with the enhancement
2. Enhance MIPv6 to carry IPv4 payloads. This
solves scenario 7,
and scenario 3 if combined with the
==> I think you should also discuss how you
assign v6 or v4 addresses
(respectively) on top of that link ? I.e., how
address assignment is done?
True. We'll look at the arguments concerning STEP again.
In summary, STEP provides a framework where
both MIPv4 and enhanced
MIPv6 would fit in. However, there are no obvious
deploying STEP rather than simply using, e.g.
MIPv4 with IPv6-
in-IPv4 tunnels. Therefore, we do not consider
STEP further in this
==> is this a fair argument? The same argument,
AFAICS, can be applied to
ISATAP, as well, and to a degree to 6to4/Teredo.
Yes, it is. We skipped that in the draft. For completeness though, we
can bring it up.
Provided that TSP is deployed, it could be used
to set up
IPv6-in-IPv4 or IPv6-in-UDP-in-IPv4 tunnels that
would allow MIPv6
mobile nodes connectivity over IPv4 networks. In
this case, TSP
would address deployment case II (MIPv6-based).
==> I think TSP should also be able to address
case I, because it provides
both v4-in-v6 and v6-in-v4 ?
As far as we understand, this would be the most straighforward way of
solving it. Do you have a suggestion of alternative ways?
In general, transition mechanisms solve the
issue of transporting,
e.g. MIPv6 over an IPv4 network (public or
private). Mechanisms in
the host for allowing the Mobility protocol to
transport multiple IP
protocol versions, rather than only the native IP
need to be addressed through extensions to the
==> is the latter sentence substantiated?
The solution "Dual-stack MIPv4-MIPv6" requires
twice the amount of
implementation as solution "Enhanced MIPv4", while
approximately the same performance in terms of
handoff latency and
transport overhead. This solution is, however,
the only one
supporting deployment case III.
==> the need and time scale for this should
probably be justified a bit more
in the document somewhere.
Yes. We'll update the draft on this.
| 11 | | | | x
| x | |
| 12 | | | | x
| x | |
==> afaics, TSP should be offering at least the
same capabilities as
ISATAP/teredo/6to4. I'd be surprised if TSP would not
support some of the
MIPv4 scenarios as well, using v4-in-v6 tunneling.
[I-D.tsirtsis-v4v6-mipv4]. Neither of these
If this solution was further enhanced to support
private IPv4 address
spaces, it would also support network scenario
cases 12 in Table 2,