Subject: REVIEW COMMENTS: draft-palet-v6ops-auto-trans-00.txt

From: "Bound, Jim" <[email-masked]>
Date: Sat, 1 May 2004 12:20:29 -0400

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