[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-larsson-v6ops-mip-scenarios-00.txt
Generic comments:
- you raise a number of (potentials) scenarios by enumerating the
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
addressed.
- there should probably be some form of problem statement
why dual MIP protocols is not a good thing. In each scenario, one might
also consider whether connection survivability is required in that
scenario.
- 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 (or operators')
networks. I.e., "where can the user roam, and still expect this to work?"
Different solutions have different assumptions on this..
semi-substantial
----------------
The issue of handoff latency would be especially important in cases
where Mobile IP provides mobility for real-time applications, e.g.
Voice over IP calls. In these cases, an absolute minimum of
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 (e.g., 0.2-1.0
seconds) that it is actually *this* what causes the problems, not as such
the number of roundtrips..
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 not really
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 appropriate MIP
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?
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 below.
2. Enhance MIPv4 to carry IPv6 payloads. This solves scenario 2,
and scenario 6 if combined with the enhancement above.
[...]
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 below.
2. Enhance MIPv6 to carry IPv4 payloads. This solves scenario 7,
and scenario 3 if combined with the enhancement above.
==> 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?
5.4 ISATAP
==> You don't seem to explicitly state which scenarions and handoffs
non-MIPv6 solutions (more than just ISATAP, of coure) support?
==> What is the assumption about deployment? Note that w/ ISATAP, you must
assume that the host will always be at the ISATAP site, e.g., doesn't roam
into the Internet.
It should be noted, however, that Teredo's default
mode of operation requires changes in the IPv6 routers, e.g. Teredo
relays.
==> I don't think this is accurate. There will need to be *added*
relays, which have to have some processing, but those don't have to be
existing ones.
Another possibility is to deploy Teredo as a stateful tunnel server
instead of the default mode where it is stateless. The Teredo server
will then act as a tunnel broker, i.e. the Teredo server will be the
end-point of the tunnel and all traffic needs to be tunneled through
it. This eliminates the need for relays and makes Teredo useful in
supporting IP mobility, e.g. in combination with Mobile IPv6
[RFC3775] and enhanced MIPv6 as discussed above
[I-D.soliman-v4v6-mipv4].
==> this is practically what a simplified tunnel broker model would be
about, with a bit more roundtrips.
In summary, STEP provides a framework where both MIPv4 and enhanced
MIPv6 would fit in. However, there are no obvious benefits of
deploying STEP rather than simply using, e.g. MIPv4 with IPv6-
in-IPv4 tunnels. Therefore, we do not consider STEP further in this
draft.
==> is this a fair argument? The same argument, AFAICS, can be applied to
ISATAP, as well, and to a degree to 6to4/Teredo.
(An argument in many of these "off-the-self" solutions is that no
modifications to MIP(s) is needed..)
I.e., only
traversal of NATs allowing IPv6-in-IPv4 tunnels through would be
supported.
==> not quite true: 6to4 through a relay would work, provided that the state
is kept at the relay, but inbound communication from other 6to4 routers
would fail, because there is no state at the NAT (unless something is
manually configured)
It should be noted, however, that the 6to4 solution
[RFC3056] states that the 6to4 mechanism is almost entirely
implemented in border routers, rather than hosts.
==> yeah, the spec says many things, most of it confusing or bogus in the
real world deployments ;-). It's in the hosts though.
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 ?
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 protocol version,
need to be addressed through extensions to the Mobility protocol.
==> is the latter sentence substantiated?
The number of signaling messages at a handoff is the same as for
native MIPv4 - registration request and reply, generating a total of
one signaling roundtrip. This solution also adds a few extensions to
the registration request/reply messages: a skippable IPv6 home
address extension of 20 bytes, and a skippable IPv6 compatibility
extension of 4 bytes, in order to transport MIPv4 over IPv6.
==> what about v6 address assignment? link-local addresses?
Deployment case I is solved by "Enhanced MIPv4". This solution also
adds minimal handoff latency and transport overhead, compared to
native MIPv4.
==> Whether TSP-like mechanisms are applicable here possibly depends on
whether DA-decapsulation of this kind of traffic would be mandated or not?
The solution "Dual-stack MIPv4-MIPv6" requires twice the amount of
implementation as solution "Enhanced MIPv4", while providing
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.
| 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.
editorial
---------
[I-D.tsirtsis-v4v6-mipv4]. Neither of these drafts, however,
==> s/Neither/None/
If this solution was further enhanced to support private IPv4 address
spaces, it would also support network scenario cases 12 in Table 2,
==> s/cases/case/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings