Subject: RE : Tunneling scenarios and mechanisms evaluation

From: "BAUDOT Alain FTRD/DMI/CAE" <[email-masked]>
Date: Fri, 12 Mar 2004 16:14:21 +0100

Hi,

Here are my few comments on the document:

1. Introduction

I think Tunnel Broker (TB) should part of the analysis, as well.

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. 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.

"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.

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.

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.

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.
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.

4.2 Mechanisms Evaluation

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

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.

Regards,
Alain. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Pekka Savola
Envoyé : jeudi 11 mars 2004 09:14
À : [email-masked]
Objet : Re: Tunneling scenarios and mechanisms evaluation

Whoops -- forgive my slip.  The address below was where it WILL be 
available.  For now, it's at:

http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-tunneling-00.txt

Sorry -- and thanks to Tim for pointing the obvious! :)

On Thu, 11 Mar 2004, Pekka Savola wrote:
[...]
> http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-00.tx
> t
> 
> Abstract
>    This memo analyses the v6ops scenarios/analysis work (Unmanaged,
>    3GPP, ISP and Enterprise) for their requirements for tunneling
>    solutions, and analyses the proposed mechanisms on how they might fit
>    in these requirements, and discusses possibilities for choosing
>    solution(s).
> 
> 
> 

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Mar 2004 18:12:39 +0200 (EET)

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..

> 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?

> ISP scenario case 2b, where the ISP backbone is not IPv6 capable, is

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?

> I wonder here what is the real meaning of ISP support in terms of

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.

> -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.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 13 Mar 2004 03:07:35 +0100

Hi,

I agree with Alain, that the way proto-41 fits. I'm not sure if we can call this NAT traversal, so may be rewording to NAT traversal or proto-41-forwarding ?

Regards,
Jordi

----- Original Message ----- 
From: "BAUDOT Alain FTRD/DMI/CAE" <[email-masked]>
To: "Pekka Savola" <[email-masked]>; <[email-masked]>
Sent: Friday, March 12, 2004 4:14 PM
Subject: RE : Tunneling scenarios and mechanisms evaluation

Hi,

1. Introduction

3.2 Unmanaged Networks

3.4 ISP Scenarios

4.1 Scenarios Evaluation

Regards,
Alain. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Pekka Savola
Envoyé : jeudi 11 mars 2004 09:14
À : [email-masked]
Objet : Re: Tunneling scenarios and mechanisms evaluation

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 13 Mar 2004 07:52:16 +0200 (EET)

On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote:
> I agree with Alain, that the way proto-41 fits. I'm not sure if we
> can call this NAT traversal, so may be rewording to NAT traversal or
> proto-41-forwarding ?

Alain did not mention proto 41 forwarding at all.. so I'm not sure 
where you got that.

NAT traversal must work in a reasonably high number of different NAT
boxes.  Proto-41 forwarding does not.  Of course, it can still be used
as an optimization in the case it's being supported, but the case
where it matters is basically the tunnel-server like approaches (TSP
and STEP) which already support or will support NAT traversal.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 13 Mar 2004 17:41:51 +0100

Hi Pekka,

Alain's comment was:

What I understood then is 2 options:
1) The NAT box is already the IPv6 end point for the tunnel ? Correct if we prefer this instead of 6to4 (because probably the cost of implementing 6to4 is the same as a TB client in the NAT)
2) We don't need NAT traversal IF proto-41-forwarding is working in that NAT

By understanding is that the number of NATs that support proto-41 is comparable to the number of NATs that support Teredo (not sure other NAT traversal mechanism).

Regards,
Jordi

---

From: Pekka Savola <[email-masked]>
Date: Sat, 13 Mar 2004 22:13:52 +0200 (EET)

> to deal with complexity of NAT traversal.

True enough.  However, I have doubts on how useful this case is in 
practice, as a large number of gateways cannot be expected to be 
upgraded -- that is, we will have to support host-centric deployment 
in any case.

However, I guess it might be useful to try to tease these two subcases 
apart to see if there are significant differences, like:

unmanaged w/o ISP support, IPv4 gateway not upgraded
  - NAT traversal or proto-41 forw. required
  - only host addressing OK, site addressing "nice to have"

unmanaged w/o ISP support, IPv4 gateway upgraded
  - host(s) require nothing
  - the gateway requires NAT traversal capability
  - must support getting at least /64

unmanaged with ISP support, IPv4 gateway not upgraded
  - NAT traversal or proto-41 forw. required
  - only host addressing OK, site addressing "nice to have"

unmanaged with ISP support, IPv4 gateway upgraded
  - host(s) require nothing
  - the gateway does not require NAT traversal
  - must support getting at least /64

So, it seems what we get here is one case where NAT traversal is not 
required, and a rather obvious conclusion that when the gateway is 
implementing a transition function, it must implement a mechanism 
which can be used to obtain at least a /64 prefix; e.g., Teredo is not 
sufficient.

This should go into the draft somehow, but as listing these would 
complicate the matrices a lot, I'm not sure whether the matrix is the 
right place to add this result.

Something obvious I missed?
 
> 1) The NAT box is already the IPv6 end point for the tunnel ?
> Correct if we prefer this instead of 6to4 (because probably the cost
> of implementing 6to4 is the same as a TB client in the NAT)

Tunnel broker is generally much more complex than 6to4, but if you buy
the concept of ND proxying, it could be a lot simpler as well.  If
not, you'll need something like DHCPv6 prefix delegation or custom
mechanisms.

> 2) We don't need NAT traversal IF proto-41-forwarding is working in

Yet, that is an optimization (or at least, cannot be the only
solution) unless we can be assured that sufficiently large percentage
of boxes do that (e.g., over 95% of the market or whatever).
 
> By understanding is that the number of NATs that support proto-41 is
> comparable to the number of NATs that support Teredo (not sure other
> NAT traversal mechanism).

Do you have more precise data than that?  Maybe it would be useful to
write it down -- like draft-jennings-midcom-stun-results-00.txt has
done about some NAT types.  I have a gut feeling that NAT proto-41
forwarding is not as common as non-symmetric NATs.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 13 Mar 2004 21:47:55 +0100

Hi Pekka,

See below, in-line.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, March 13, 2004 9:13 PM
Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation]

> upgraded -- that is, we will have to support host-centric deployment 

I don't agree. In general is in the other way around. Is more and more often that the routers, gateways, etc., are updated from time to time, with new firmware or software.

> which can be used to obtain at least a /64 prefix; e.g., Teredo is not 

Agree.

> right place to add this result.

I think if we are trying to approach to a more complete solution, we need to include these options in the draft/matrix. As I indicated in the meeting, I'm sure there are 100% perfect solutions, but they will take long time to be ready; but at the same time, completing the matrix, even when complicating it a little bit, is mandatory, to cover as much as possible the real market situation, and consequently provide the needed transition tools, to facilitate how the deployment can happen (in the real market).

> not, you'll need something like DHCPv6 prefix delegation or custom

I meant that the NAT can be the end-tunnel point (for a TB, and if possible automatically configured, but we don't have this right now), OR the NAT box is upgraded to support 6to4. Note that this is already happening. I read a couple of weeks ago about an upgrade for an existing router (IPv4 only previously) to support 6to4.

> of boxes do that (e.g., over 95% of the market or whatever).

Our testing, considering not just the number of models and manufacturers in the market, but also how many units there are in the market from each manufacturer, shows about 85% supporting proto-41, but I guess this will improve. I'm not sure if is good to mention here specific brands and models, but in any case is simple to understand. We can have a market with 100 models (just an example), but one of the models has 60% of the market sharing and supports it. That means that we have already 60% of the market supporting this feature, just add the others from the pool of 100, and you have the 85%.

> forwarding is not as common as non-symmetric NATs.

You feeling is wrong ;-), see my previous reply. We have gathered this information from different sources for months. Just an example, only one of the products being sold/installed in Spain by the xDSL provides, didn't supported proto-41-forw., and by the way, is not the one that has the bigger market sharing.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 13 Mar 2004 23:00:24 +0200 (EET)

On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote:
> I don't agree. In general is in the other way around. Is more and
> more often that the routers, gateways, etc., are updated from time
> to time, with new firmware or software.

For technical users, yes; for non-techies, I have serious doubts about
that.  DSL products bought or provided by the ISP stay there for 3-5
years at least, and they don't have a software upgrade; even if they
had, the average user wouldn't know or dare to install it.

If an IPv6 product (e.g., Microsoft's some new shiny new patch kit to
use v6 in peer-to-peer) was being deployed, saying "upgrade your NAT
box" is not an option.  The case where we can't do anything about the
deployed base is the minimal target: it must be supported as well as
it can be.  If we can, we might also want to create optimization(s)  
for the cases where some box has been upgraded (or not).

> I think if we are trying to approach to a more complete solution, we
> need to include these options in the draft/matrix. As I indicated in
> the meeting, I'm sure there are 100% perfect solutions, but they
> will take long time to be ready; but at the same time, completing
> the matrix, even when complicating it a little bit, is mandatory, to
> cover as much as possible the real market situation, and
> consequently provide the needed transition tools, to facilitate how
> the deployment can happen (in the real market).

The real market situation can be handled if we design solutions that
work with the lowest common denominator (e.g., no NAT/gateway
support), right?

> Our testing, considering not just the number of models and
> manufacturers in the market, but also how many units there are in
> the market from each manufacturer, shows about 85% supporting
> proto-41, but I guess this will improve. I'm not sure if is good to
> mention here specific brands and models, but in any case is simple
> to understand. We can have a market with 100 models (just an
> example), but one of the models has 60% of the market sharing and
> supports it. That means that we have already 60% of the market
> supporting this feature, just add the others from the pool of 100,
> and you have the 85%.

I think it's OK to mention brands and models -- there's precedent in 
draft-jennings-midcom-stun-results-00.txt and a lot of other 
documents.  We might not want to publish those results as an RFC, but 
I think it would be useful to make that list public so folks could see 
if they something to add to the list, see whether they have different 
experiences, see if their product would be supported or not, etc.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 13 Mar 2004 22:25:03 +0100

See in-line.

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, March 13, 2004 10:00 PM
Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation]

> had, the average user wouldn't know or dare to install it.

No, I don't think so. More and more users keep updating their equipment, even when non-techies. But definitively, no longer the equipment is there for so long time, I will say less than 2 years, actually.

> for the cases where some box has been upgraded (or not).

If a wide spread game or product is in the market and requires the user to upgrade their box, even purchase a new one to play that game, you can make sure that they will do so ;-) The only problem right now is the price for IPv6 enabled routers. Hopefully low cost models will come soon from Taiwan and China.

> work with the lowest common denominator (e.g., no NAT/gateway

Yes, but choosing only 1 or 2 options (is just an example, I'm not counting the real situation right now) may be not optimal, specially if we have a 3rd one that could be more optimal in, let's say more than 30-40% (may be even less percentage is acceptable) of the cases. If that's the case, then we should include that option in our matrix.

> experiences, see if their product would be supported or not, etc.

Ok, then as I can remember, we have all the Cisco, 3Com, Linksys, Nokia, D-Link, NetGear, Draytek, SMC, Conceptronic, Allied-Telesyn, Develcon, Perle, Trinexus, Yamaha, Zyxel, NEC and Buffalo.

In addition, looking into the "firmware" of these products, I found as a common denominator that they work if they have IOS, VxWorks, QnX, Linux, USSoftware, and BSD. Some times the OS is hidden, but I've been able to discover it or checking with the manufacturer or some document around.

Note that I've not tried all those (may be about 40% of them only), but we asked in this list and several others, the people to try out and this is the result of the feedback received.

The only one that I've found myself that failed to support proto-41-forwarding was Efficient Networks (I believe now belongs to Siemens).

If you look into the market sharing, I'm very convinced that this is even higher than 85%, but just to be conservative ...

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Mar 2004 13:23:18 +0200 (EET)

To summarize the inline discussion:

 - counting on NAT boxes implementing v6 and getting those boxes in 
the field would probably require an IPv6 killer application, and IMHO 
we shouldn't be counting on it

 - I don't yet know how to integrate "v6 support in the gateway" in 
the document (somehow in the matrix, vs elsewhere).  If you have 
specific suggestions, fire away.

 - I think it'd be very useful to publish as much info on proto-41
capable (or incapable) boxes as possible; I think that would help us a
lot.  (The same applies to different NAT types wrt. Teredo, but that's
already being done in a separate draft.)

More detail inline..

On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote:
> No, I don't think so. More and more users keep updating their
> equipment, even when non-techies. But definitively, no longer the
> equipment is there for so long time, I will say less than 2 years,
> actually.

Let's just say that we disagree on this.

> If a wide spread game or product is in the market and requires the
> user to upgrade their box, even purchase a new one to play that
> game, you can make sure that they will do so ;-) The only problem
> right now is the price for IPv6 enabled routers. Hopefully low cost
> models will come soon from Taiwan and China.

Certainly.  But you're counting on a killer application to appear, 
which would make the user to justify investing into a new NAT box, as 
well as spending time on working on a solution.

None have appeared yet, so I do not want us to base IPv6 connectivity
mechanisms on that premise.  These should work (or at least a subset 
of them), even if the killer app doesn't turn up which would make the 
users want IPv6 so bad that they would be willing to buy new hardware, 
require IPv6 from their ISP, etc.

Then we would be where we want to be, of course, but we shouldn't 
count on that.

> Yes, but choosing only 1 or 2 options (is just an example, I'm not
> counting the real situation right now) may be not optimal, specially
> if we have a 3rd one that could be more optimal in, let's say more
> than 30-40% (may be even less percentage is acceptable) of the
> cases. If that's the case, then we should include that option in our
> matrix.

I think this depends on the complexity of the solution and how big an
optimization it would actually offer.

Currently, the case where NAT gateway implements v6 (like 6to4) does
not seem useful enough, but might become so in the future (and it 
might not hurt to consider how the transition landscape could change 
if that happens).  So, I certainly think it should be mentioned in the 
document, but I'm not yet sure how.  Being included in the matrix 
could be an overkill and difficult, but leaving it out might cause us 
to omit some mechansims (or requirements) which would would be useful 
in the scenario.

So, I'm open to more specific suggestions (than just "include it in
the matrix").  Include it how?  Reword the scenarios how?  I'll 
probably try to think of some means myself, but if folks feel this is 
an important issue, feel free to help... :-)

> Ok, then as I can remember, we have all the Cisco, 3Com, Linksys,
> Nokia, D-Link, NetGear, Draytek, SMC, Conceptronic, Allied-Telesyn,
> Develcon, Perle, Trinexus, Yamaha, Zyxel, NEC and Buffalo.
> 
> In addition, looking into the "firmware" of these products, I found
> as a common denominator that they work if they have IOS, VxWorks,
> QnX, Linux, USSoftware, and BSD. Some times the OS is hidden, but
> I've been able to discover it or checking with the manufacturer or
> some document around.
>
> Note that I've not tried all those (may be about 40% of them only),
> but we asked in this list and several others, the people to try out
> and this is the result of the feedback received.
> 
> The only one that I've found myself that failed to support
> proto-41-forwarding was Efficient Networks (I believe now belongs to
> Siemens).
> 
> If you look into the market sharing, I'm very convinced that this is
> even higher than 85%, but just to be conservative ...

Market share is probably an important consideration, but not the only 
one.

Could you get this written up in some form (e.g., a web page,
internet-draft, etc.) with as much detail as possible (and when in
doubt about the information, with contact info etc.).

This would probably make it much easier for folks to see how the 
support SHOULD be and state if there are inaccuracies, start to use 
this if they didn't know their own NAT even supported this, etc.

It may also be worth noting which features are supported.  I recall
there was some confusion wrt. being able to configure an internal host
to receive proto-41 packets (or requiring any other configuration) vs.  
the NAT box working automatically out of the box, or whether it
requires some configuration [what kind of config?] (the out of the box
operation is a very important consideration here).