Jordi,
What you have done is describe a product feature
to automate transition, but not an engineering specification with proper details
that convey what we must actually do and agree to in this working group. I
also suggest below focus on stationary not mobility, and also focus only on the
home deployment model.
I do not think it would ever be possible to get
consensus on this idea but maybe. But your spec is just an idea not a
technical specification. That is nice of you to send to us but this has no
technical depth to resolve the technical parts that would be required to even
contemplate all the affects to our current IPv6 transiiton mechanisms.
It
also assume software that does not exist to determine best approach and would
add more software to the transition too.
Lastly DSTM should be included
for this reason, unless it is a home network, because on a dominant IPv6 network
it can be determined well if IPv4 is required from the DNS record returned and
then DSTM is one option users have to deploy. But we do not recommend this
in UMAN type envoironments per DSTM deployment.
Comments on the spec
directly below prefixed with JB.
This needs much discussion if it should
be a WG. I think it does poke at us in the WG to ask ourselves what
automation do we need for transtion as a tool if any? So your idea is good
input to us as something to think about in general is my
view.
-----------------------------------
Abstract
This draft evaluates a method called "auto-transition" to ensure
that
any device can obtain IPv6 connectivity at any time and
whatever
network is attached to.
JB: Add text that this
is to use IPv4 over IPv6 or we need to discuss native IPv6 more
below.
The method looks for the best transition mechanism
according to
performance criteria as well as the scenario where
the device is
located.
JB: I don't think this will ever
be possible. We can never know all the performance metrics to make such
and auto choice. Also this assumes users want to use multiple choices and that
either needs to be stated as an assumption or like wording.
By implementing such auto-transition method in either or both
end
nodes or middle boxes (CPEs), users can always obtain
IPv6
connectivity with no human intervention.
JB: The
integration of many mechanisms and security ramifications will make this
undesirable to many users is my input as deployment analysis.
1.
Introduction
The main goal is to facilitate the IPv6
deployment in a seamless way
for devices, users and
applications. Lots of devices and applications
around us will
benefit obtaining IPv6 connectivity everywhere: home
automation,
wearable devices, cars, PDAs, mobile phones, peer-to-peer
applications, remote control applications, etc. IPv6 is suitable
to
solve the network requirements that those
devices/applications will
need: addressing space, end-to-end
secure peer-to-peer communication,
autoconfiguration features
and so on.
JB: This is marketing and unnecessary text for the spec.
Also I like the abstract to be first paragraph of the introcudtion and forces
clear crisp initial statement from authors of specs. The abstract needs
more content.
IPv6 provides autoconfiguration features,
enabling devices to work
according to the plug-and-play
philosophy, that is with no manual
intervention. However they
only can be applied once the device has
obtained IPv6
connectivity. On the other hand, while native IPv6
connectivity
is not available everywhere, there is not a good
"auto-transition" to ensure this connectivity.
JB: You state the obvious
IMO and not necessary and I am in the second paragraph and still do not see the
point.
While devices are located in a native IPv6
environment, no manual
intervention is required, so non
technical users can take advantage
of IPv6. However until all or
most of the networks are IPv6 native,
we need to ensure that the
same devices and users can use a
transition mechanism that
ensures the best possible IPv6
connectivity, without any
technical knowledge. Is not acceptable
require to the users to
make manual configurations in order to get
the IPv6
connectivity.
JB: So is this only being proposed for the home
environment? I suggest doing that is prudent. This will never be
deployed IMO in an Enterprise or ISP network.
The mechanism
will deal with all the tasks required to configure
automatically
the best IPv6 connectivity at anytime, in any network
scenario,
which include native IPv6 connectivity detection and
transition
mechanism selection if required. It can be implemented
either in
stand-alone devices (hosts, PDA, etc.) or middle boxes like
CPE
routers.
JB: Again suggest limiting the scope of what your proposig to
UMAN or Very small businesses like the Dentist office.
2.
Auto-Transition Overview
When the device is attached to the
network, the mechanism first must
check if native IPv6
connectivity is possible.
JB: OK so is this extra networking software to
do this? More below.
If so, either or
both
stateless [1] or stateful autoconfiguration [2] mechanism
are
performed. Otherwise, the auto-transition mechanism should
try to
obtain IPv6 connectivity by using the best transition
mechanism
according to the network where the devices is
attached.
JB: This is not clear to me logically. If IPv6, If
stateless or dhcpv6 do stuff, else do auto transition? I think that is
what your saying? Why would stateless or stateful not exist and under what
circumstance? I can't see that because any node I know at least does
link-local stateless immediately?
Later, the conditions of
the network can change, even the user/device
can change the
location while moving.
JB: Now your heading down mobility / nomadic
path. I suggest, if this is to be WG item, that it deal with stationary
networks and nodes so we can get that right. Mobility is a completely different
analysis. Baby steps is my input.
Consequently the
attachment
point to the network can be different, and the
previous transition
mechanism no longer be so
convenient.
JB: "convenient" that is not a technical term and do you mean
it will not work or perform and if so what informs the implementation of what
you propose?
The auto-transition mechanism
has to monitor periodically the network parameters (i.e. IPv4
address, loss, delays, etc.) in order to detect those changes
and
decide if another transition mechanism different to the one
currently
being used is convenient and provides better
performance to activate
it.
JB: so this software has to
exist on the clients? please do not try to even attempt addressing
mobility or nomadicity.
All this process should be ideally
automatic in order to avoid the
user to make any manual
configuration.
JB: so its not always automatic?
At
the most, users only should
introduce some parameters by means
of a wizard during the
installation process of the application
that implements the
auto-transition mechanism, but once it is up
and running, all the
tasks should be made by the system and no
manual intervention
required.
JB: this is a product
requirement not a standards requirement we build in the IETF. Nice for
summary but not relative to the engineering work we do here.
3.
Auto-Transition Requirements
If native connectivity is not
available the auto-transition mechanism
must choose the right
transition mechanism to be used to ensure the
connectivity.
JB: I don't agree unless your speaking about a home
environment and then I believe it should be config option to the user with
explanation or from the ISP.
A number of transition
mechanism have been defined already: Teredo,
TB/TS, TSP, STEP,
ISATAP, 6to4, tunnels, etc.
JB: Nothing you stated above should preclude
not stating DSTM above it should be stated and listed it is a deployed mechanism
as the others.
3.1 Selection of the proper transition
mechanism
A few scenarios with particular network
requirements had been defined
already ([4], [5], [6], [7]). Not
all the transition scenarios fit in
such network scenarios, as
being evaluated at [8], trying to make the
best fit to each
scenario.
JB: This makes no sense to me you must explain why you say this
in relation to [8] or are you trying to appease Pekka :--)
The auto-transition mechanism may take into account the results
shown
in [8], although it is also possible a wider focus to
select the best
transition mechanism to be used. What the end
user always demands is
the best performance on the IPv6
connectivity, so it should be the
main criteria to choose the
right transition mechanism.
JB: Same comment as above. You should
add more discussion and text here and what you mean in this
spec.
Distance, delays, loss, bandwidth, etc., are some of
the related
parameters that could be used as metrics to be
measured for knowing
the link performance. A device can present
different values of such
metrics according to the transition
mechanism that is being used even
when attached to the same
network.
JB: You really need to state how below but we shall
see.
loop
detect_scenario
if
(native_IPv6_available and native_priority)
use_native_IPv6_connectivity
else
if (first_check or
performance_check_allowed)
check_performance
use_best_mechanism
endif
endif
configure_connectivity
wait (link_check_timeout)
endloop
Figure 1: Simple Auto-transition
algorithm
JB: You missed your early if statement what if stateless or
stateful exists in the above?
It is important to note what
each task or parameter means:
o detect_scenario: This
task deals with detecting the scenario where
the device willing to have IPv6 connectivity is located. It
could
check if native IPv6 is available, if a
public IPv4 address is
available, if a NAT is
being used and what type, if there is a
proxy
or firewall, or if other protocols can be operated.
o
native_IPv6_available: Detects if native IPv6 is available.
o native_priority: Detects if native IPv6 has priority,
for
instance, even in the case the performance
is lower than
alternative transition mechanism
that may be used. This condition
could be set
by the OS, or even under user or applications
control.
JB: I argue there is not way to do this at
all.
o use_native_IPv6_connectivity: Configure the
interface to use
native IPv6 connectivity,
using stateless or stateful
autoconfiguration,
upon their availability.
o first_check: Defines if
this is the first time this check is being
done after an interface reset.
o
performance_check_allowed: Defines if the performance of
the
selected mechanism can be measured after
selected, for instance,
to avoid traffic being
generated in non-flat rate links (3GPP,
ISDN,
...).
o check_performance: According to the detected
scenario, a number of
mechanisms could be
used. This task checks the performance that
each of such transition mechanism provides, including native
IPv6
if available, by measuring delays and
losses. The mechanism subset
will be defined
by taking into account [8], but others could
be
considered.
o
use_best_mechanism: According to the measurement results, the
best
mechanism is
selected.
o configure_connectivity: Either native IPv6
connectivity or the
best available transition
mechanism is configured.
o link_check_timeout: Once
the IPv6 connectivity is obtained, the
auto-transition mechanism periodically monitors the link
status.
The delay between consecutive checks
is defined by this variable.
A possible list of mechanism to
be checked, ordered by preference
could be:
1. Native IPv6 Connectivity
2. TS with proto-41
([3])
3. TS with UDP
4.
ISATAP
5. STEP
6.
6to4
7. Teredo
JB: Add DSTM nothing has been
specified in the spec to preclude the use of DSTM or is it you believe not say
DSMT is correct politically?
3.2 Change of transition
mechanism
Change of transition mechanism refers to the task
to abandon the
transition mechanism that is actually being used
and start to use
another one that presents better performance.
This is not an easy
task at all, since it involves at least two
important issues:
1. To maintain the current IPv6
address. This is a must since
otherwise
applications with communications opened will not
work.
Specially important is the case
which the auto-transition
mechanism is
implemented in border devices that provide
native
IPv6 connectivity to the whole
network. Either the prefix network
(i.e.
RA), or the IPv6 addresses (i.e. DHCPv6) that they
provide,
must be able to keep the IPv6
addressing parameters. If the
auto-transition mechanism has to include the possibility
of
changing the transition mechanism
used without discarding the
current
connection state, it is necessary to define a method
that
solves this issue. MIPv6 concepts
could be applied.
JB: So now you must keep state at the edges and please
explain what you mean and what parts of MIPv6 can be applied. But I
sugggest you not botoher with Mobility for now.
2.
User authentication without human intervention. The philosophy
of
the auto-transition mechanism is that
all the processes are done
automatically, with no human intervention. So, for instance,
if
the device running the
auto-transition mechanism needs to
contact
with a TB different to the
actual one, and it requires user
authentication, the process should be transparent to the user.
It
could be based on parameters (login
and password) configured
through the
wizard during the installation process.
AAA
mechanisms should be
used.
JB: AAA is good for the home network but not strong enough for CPE
boxes is my input IPsec at a minimum is required. How does Ipsec affect
this is important to understand.
JB: No comment on your layer tunnels it
was just stating current state of art for that function.
JB: I will not
comment on Nomadicity we first need to discuss stationary and get that
right.
Regards,
/jim