Re: draft-palet-v6ops-auto-trans-01 comments

[Pekka Savola <pekkas@netcore.fi>]

Inline.. (I snipped some more trivial issues)

On Sun, 1 Aug 2004, JORDI PALET MARTINEZ wrote:
> > substantial
> > -----------
> > 
> > In section 3.3, this doc goes on to state that building v6 tunnels over
> > UDP is not always possible as some middle boxes don't forward those
> > packets. 
> > 
> > I'd argue that this is a scenario we want to declare out of scope.  If
> > such a box really exists, it's more likely than not that the user is not
> > supposed to punch holes in the NAT/firewall.  We can simplify this a lot
> > if we can remove whole section 3.3 and its subsections on HTTP, TCP or
> > other tunnels. 
> 
> I partially don't agree. I agree that some times the "network
> administrator" (i.e., enterprise), don't want to the user to punch
> the NAT/firewall, but in some circumstances, the issue is more a
> non-technical knowledge of the user to do that, so we need to
> describe a solution (which can be or not provided in the specific
> implementation).

I'm not sure which scenario you're targeting and who you refer to with
"user".  Unmanaged networks?  All of those NAT boxes etc. practically
allow you initiate new outgoing UDP "sessions", right?  Enterprise
networks?  Many allow outgoing UDP sessios as well, and those which
don't disallow it for security etc. reasons and we don't want to
cirucmvent that (and such organizations very likely block other kinds
of packets as well, such as TCP so it wouldn't work in any case).

Therefore I think having this consideration in the draft is 
counter-productive, at least without strong warnings and disclaimers.

> >    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
> > 
> > ==> this algorithm doesn't actually work (AFAICS) because
> > use_best_mechanism is inside the loop.  Shouldn't it be outside the loop?
> > Or did you mean that it selects the best of *so far* configured/tested
> > mechanisms? 
>
> Yes, once we detect the scenario, and what mechanisms are possible,
> one is "best", then we actually enable it.

OK; (I misunderstood the algorithm at first -- the loop doesn't 
iterate over the mechanisms, but over time, to detect if the scenario 
the user is in might have changed.)

> >   A possible list of mechanisms to be checked, ordered by
> > preference
> >    could be:
> > 
> >    7.  DSTM
> > 
> > ==> I think you can strike this from the list, because this draft
> > discusses how to get v6 everywhere... DSTM already assumes v6, and is a
> > solution for getting v4.
> 
> Yes and not ... we are considering to extend this document to cover
> both sides of the history ... then DSTM could play an important
> paper there.

I'd keep that out for now, or just cover it in an appendix (or the
like)... because the auto-discovery on v6-only networks vs v4-only
networks has really different assumptions..
 
> > 3.2  Change of transition mechanism
> > 
> > ==> this section, or something close to it, should probably discuss when
> > it makes sense to have multiple transition mechanisms active at the same
> > time. For example, you might still want to activate 6to4 even if you have
> > a tunnel, for optimization purposes.
> 
> You mean activate multiple transition mechanism and actually make
> use of both ? Not really sure if we want to put the host in a
> multi-homing situation. Is this good ?. Or I'm not figuring out what
> you are trying to say ?

Isn't this what e.g., Windows hosts are doing today?

That is, you can use 6to4 or Teredo (for example) as optimization
methods when talking to 6to4 or Teredo nodes, even if you have native
IPv6 connectivity.  The case is the strongest with 6to4.  This
obviates the need to use a relay in the network, and optimizes the
connectivity (if you assume that direct v4 connectivity would be
optimal).

The use of such a mechanism could be either outbound only (e.g., 
practically a host- or site-specific outgoing 6to4 relay), or 
inbound/outbound (e.g., would generate 6to4 addresses as well and 
publish them, so that 6to4 nodes would have better connectivity when 
they initiate connections to your DNS names).

> > ==> I don't quite understand how you mix MIPv6 into this.  I didn't
> > understand the second sentence (starting with "If chosen,..") or the last
> > sentence (I mean, any mechanism is compatible with HA, as if you have HA,
> > you can have whichever address at all because it's just your CoA).
> 
> Yes, we mean that if MIPv6 is choosen as an option (either
> automatically or by the user by means of a wizard), then ... The
> problem here is if the user has access to a HA or not.

You mean that the situation is greatly simplified if the user can use 
a Home Agent, but you'd want to also address the scenario where the 
user does not have a Home Agent?

That's OK if you make it clearer, but I'd like to reconsider whether 
trying to reinvent (parts of) Mobile IP makes sense.. (it would better 
for the user to just use Mobile IP!)  -- at least you shouldn't aim to 
achieve the same (but only a subset of scenarios) as Mobile IP..
 
> > ==> this section seems overlongly long and detailed.. I think the basic
> > thing you're saying is that the network could provide a means to help the
> > user choose their mechansism (my example: e.g., a DNS record),
> > describing different options and possibly giving preferences as well.
> > This is in particular because policy-based networks didn't really get
> > into a good swing and get deployed.  Thus, I'd only keep the first 1-2
> > paragraphs, and those from the end starting with "Whether the network
> > provides".. 
> > 
> 
> Our point here is precisely that the provision of PBN could motivate
> the ISPs to start the transition, because they can take the
> opportunity to do other "policy" based services at the same time. Is
> not only a DNS record, but a managed transition that also provides
> the ISP the way to control the process and provide higher quality of
> the transition service.

I mean, do you suggest that the ISP would deploy PBN just (initially) 
for v6 transition?  This doesn't seem practical to me.. and I doubt 
that it would happen -- hence I would like to reduce the emphasis of 
PBNs here.  It's really something that should be described in a 
totally separate I-D (or appendix, or whatever).

> >   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.
> > 
> > ==> I'd do s/and what type/(and possibly what type)/ because it might not
> > be feasible to do that in auto-trans, if the mechanism has to detect the
> > NAT type (like Teredo) in any case -- or were you referring to whether it
> > forwards proto-41 or not?
> 
> I don't understand why you say that auto-trans can't do that ? Or
> you mean that is not useful because is done already by the mechanism
> itself ? But if so, that only happens once the mechanism is
> launched, and auto-trans goal is to select the right mechanism
> before its started.

Yes, I meant that it probably isn't feasible to do that by auto-trans 
because it's done by the mechanisms.  If you do that prior to 
launching the mechanism, you do a lot of duplicate work.  If you do it 
after launching a mechanism, you aren't really "detecting" anything in 
auto-trans, just using the knowledge which the mechanism learned about 
the environment.

How I see this is that auto-trans, in its most basic form, should
first try to cut down the number of mechanisms to evaluate based on
"passive analysis" (e.g., checking whether IP address is private or
not).  

After that, it needs to test the mechanisms in some order: that could
be done either by launching the mechanism and seeing if it succeeds or
not (and if not, try to figure out how it failed, and try the next
one), or by reproducing some code from the mechanisms and try to do
some "active investigation" in the network itself (e.g., send a
specific kind of test packet outside (where?) and see if you get it
back).  The former approach would possibly be preferable.


> >  So, for
> >        instance, if the device running the auto-transition algorithm
> >        needs to contact with a TB different to the actual one and it
> >        requires user authentication, the process should be transparent
> >        to the user.
> > 
> > ==> I didn't quite understand which TB is the "actual one"
> 
> In the case that you are already connected, for example, to a TB and
> you're moving to a network that offers a better TB option (nearer
> one).

how about "the one being already used"

> >        *  TSs that do not require authentication process.  They are TSs
> >           that provide IPv6 connectivity and they do not make any
> >           authentication process (TEREDO, 6to4, etc.).  This approach
> >           does not represent any innovation, so the auto-transition
> >           algorithm just contact to the TS and the IPv6 connectivity is
> >           obtained.
> > 
> > ==> "doesn't represent any innovation" -- I don't understand, remove ?
> 
> Possibly "The auto-transition approach doesn't represent any
> advantage in this case".

OK :)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings