Re: RE : Tunneling scenarios and mechanisms evaluation

[Pekka Savola <pekkas@netcore.fi>]

Thanks for your comments.  You raise tough issues, and I'm not sure if 
I see the point in some of them.  Maybe you can elaborate a bit..

On Fri, 12 Mar 2004, BAUDOT Alain FTRD/DMI/CAE wrote:
> 1. Introduction
> 
> I think Tunnel Broker (TB) should part of the analysis, as well.

I have to disagree -- AFAICS, TB (RFC 3053) is just a concept, TSP 
being an instantiation of that concept.  I'm not sure how to even 
compare that if it was included..

> 3.2 Unmanaged Networks
> 
> Case 2 seems to match ISP case 2a (where the connection network
> cannot be upgraded), unless it is a compilation of unman case C and
> ISP case 2a. 

Yes.

> Anyway, in one case the ISP cannot cooperate with unman
> network, while it can do so in the other case. The appropriate
> solution may then meet different requirements, e.g. oportunistic
> mechanism may or may be not suitable.  I guess this need some
> clarification.

I'm not sure if I understand what you meant with "cannot cooperate 
with unman network" ?

Do you mean that the unmanaged user does not use (or cannot use) the
mechanism that the ISP is using?  The user should get that support 
then, or if not, the case would equal the unman case 1.1 -- when ISP 
does not provide any support.

> "NAT traversal must be supported." This is not true if the tunnel
> ends in the gateway where the NAT function is usually located. I
> think this is important, since the solution to deploy does not need
> to deal with complexity of NAT traversal.

True.  On the other hand, practically, it seems clear that we cannot 
expect *all* of these gateways to support IPv6 -- so we'll have to 
cope with every scenario.  However, this does not say that NAT 
traversal must be _used_ -- it just has to be supported in the case 
that it's needed.

One could certainly break the unmanaged cases into smaller pieces,
depending on whether IPv6 is supported in the gateway device or not,
but I think the result in the end is just the same, and we would not
gain anything by splitting a larger scenario to a few smaller pieces
(as we would still have to wrap it up -- to use the same mechanism as
it would not make sense to specify two for the slightly different
cases).

Or, did you mean that the "IPv6 in the gateway via a tunnel" is a 
significant case, and it might be useful to try to analyze it 
separately?

> 3.4 ISP Scenarios
> 
> "ISPs do not have specific scenarios which need to be addresses which
> haven't been already mentioned"
> 
> ISP scenario case 2b, where the ISP backbone is not IPv6 capable, is
> not discussed here.

It isn't, because the answer is obvious, especially after the Monday
meeting: configured tunneling or something like BGP tunneling.  I
guess this could be spelled out..

> Anyway, I think that there is a large difference between "obtaining"
> connectivity, as discussed in the previous section 3.3, and
> "providing" a connectivity as an ISP. ISPs have strong requirements,
> at least, on user identification, in order to make sure the
> connectivity is provided to its customers with some reasonable load
> (and without unpredictable overload), and on addressing since the
> duly identified customer may benefit from some address/prefix
> delagation from the ISP' TLA.

I'm not sure if I see fundamental issues here.  All the mechanisms
which are meant to be used in the "ISP-assisted" method already
provide pretty good means for identifying the user as the ISPs own
customer -- either through the identification of IP address, or
through other means.

I didn't quite understand your comment on the load.  That's of course 
certainly a factor, especially with tunnel-server -like models.  Could 
you elaborate?

All the mechanisms on the table for "ISP-assisted" case are already 
offering an address or prefix from the ISP's address block (in 
contrast to someone else's) so I'm not sure if I see your point.  Or 
were you saying that we should spell out whether the user gets an 
address, a subnet /64 prefix or a site /48 prefix through the use of 
the mechanism?  

There are certainly differences there, but as the mechanisms are not
meant to be permanent, I'm not sure how important that would be from 
the _ISP's_ perspective at least.

> 4.1 Scenarios Evaluation
> 
> I think the matrix should match here all the identfied scenarios
> from 3GPP, UNMAN, ISP and ENT, and not a subset of them.

The matrix is intended to include the specific scenarios from all the 
documents which have been identified, while avoiding duplication.  Can 
you identify some scenarios which are missing?

> Two columns maybe added: one dealing with "user identification" and
> another one dealing with some prefix delagation means, in order to
> actually complement the ISP column.

I think we'd have to have a bit more precise idea what these would 
imply.  Could you for example describe the requirements for user 
identification in each case (and rate the requirements)?  What would 
be sufficinet user identification?

And similar about prefix delegation.  I guess what you're saying is
that different scenarios require different amounts of addresses?  And
similarly, different mechanisms provide a different amount of
addresses.

Note that in many cases, there's no stopping from each host in the 
network running the mechanism on its own, getting an address from each 
tunnel.  How would that get rated in the "amount of addresses" field?

> 4.2 Mechanisms Evaluation
> 
> I wonder here what is the real meaning of ISP support in terms of
> features or functions.

It just simply tries to imply whether support from the ISP is required 
or not.  Of course, this is difficult to judge -- is e.g., a 6to4 
relay somewhere in the network, by some other ISP considered "ISP 
support"?  I don't count it as such.

> Anyway, to get a more compltete picture, I would add columns for: 
>
> -terminal/gateway: if the macnism applies to a terminal only, a gateway only or both
> with the idea of complement ISP column: 
> -user identification
> -address/prefix delegation means.

Similarly, I would like to understand the terminal/gateway distinction
better, i.e., how it would be useful for this comparison?

When it comes to mechanisms proposed, Teredo is terminal-only, as well
as is ISATAP (to a degree anyway -- some releases have provided
support for prefix delegation etc. but I don't think this exists at
the moment -- and would be terribly insecure if it did).  TSP and STEP
work in both.  But with the current requirements, it's fine to just
run the mechanism on the hosts themselves, not on the gateway, thus
making this point a bit of moot.

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