[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : RE : Tunneling scenarios and mechanisms evaluation
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..
AB> TB is part of the analysis, then, not by its own, but through TSP ;)
Basically, if TB is not directly part of the analysis, it should be
explained.
> 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.
AB> Well, I mean that "ISP support" meaning is unclear... It seems that
the ISP, either is passive, or is providing direct IPv6 connectivity.
ISP case 2a is actually in the between.
> "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.
AB> Right. And an ISP may not support every scenario.
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?
AB> IPv6 in a gateway via a tunnel is very close to "IPv6 in the
gateway", i.e. natively. Everything behind the gate should be exactly
the same in both cases. It sounds like a significant case indeed.
> 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.
AB> I mean here that, in order to be really manageable,
identification/delegation has to be explicite, as well as it is with
IPv4, with a clear connection between the user and prefix.
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?
AB> I mean here that some "open" or "opportunistic" mechanism are
actually available for all, and one just neeed to pick up connectivity.
In this case, and without any user control mechanism, the number of
users and the trafic load come unpredictable.
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.
AB> The point is that, once the mechanism is removed, the others means
or behavior (from the user and the ISP point of view) should remain, as
much as possible, unchanged.
> 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?
AB> My point is that we simply should find in the matrix exactly the
cases identified into scenario documents (unman csae, A,B,C,D, ISP, case
2a, 2b, etc...)
> 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.
AB> Explicite mechanism maybe enough here. For instance, embedding an
IPv4 addresse into IPv6 one, is an implicite mechanism.
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?
AB> The distinction here is that a mechanism that applies to a gateway,
applies for the whole network behind the gateway, while a mechanism that
applies to a terminal has to be duplicate.
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.
Alain.