SUMMARY: Tunneling scenarios and mechanisms evaluation

[Pekka Savola <pekkas@netcore.fi>]

Hi,

As the list has had over 100 messages in less than a week, with a lot
of subthreads, let me try to summarize what seem to have been the most
important issues; let's hope I didn't forget or misinterpret anything.  
Some of these threads are still active, so this, like internet-drafts,
is still work-in-progress :-)

On the next steps and/or "action points":
-----------------------------------------

[If you're interested in working on these contact the chairs and/or
the persons already on the job..]

 - we should produce a draft describing different issues relating to 
   "auto-discovery" of tunnel servers quickly. (e.g., anycasting, DNS, 
   DHCP, etc.).  This would help us to understand the problem space 
   better.  Jordi already promised to help with this, but more eyes & 
   fast fingers might not hurt to get a first version out quickly 
   (e.g., 1-2 weeks).

 - we should produce a draft describing how to select the "right" 
   transition mechanism in all the cases, and what are the 
   implications.  That's less critical work, as we don't yet know 
   which transition mechanisms we would have on the table, but useful 
   as well.  Jordi, at least, will be working on this, but more eyes & 
   fast fingers would not hurt, obviously.

 - we need to figure out more exactly how widely proto-41 forwarding 
   is supported, and precisely how.  This could be done in a draft or 
   a web page.  This is rather important as well, if we want to make 
   assumptions on the availability of the feature.  I assume Jordi 
   will be working on this.  (Similarly, it's important to know about 
   the different NAT types wrt. Teredo, but this is already in 
   progress in MIDCOM WG it seems..)

 - we should produce a draft describing the issues relating to 
   concerns about the division of IPv6 Internet into three: native, 
   6to4 and Teredo.  This should also describe the approaches to 
   mitigate the problems (e.g., the precise means of "local relay 
   deployment").  This should form a basis for "cost analysis" people 
   called for in the IETF59 meeting when there was no concensus for 
   going forward with Teredo yet.  This is critical work and the first 
   draft should be out within a month at most.  No volunteers at the 
   moment -- contact the chairs.

 - we could produce a draft or some kind of list of "desirable 
   features" if we were to design a new tunnel broker/setup protocol, 
   i.e., try to combine the features of the current proposals, and try 
   to look for what's missing and/or could be better.  It is not yet 
   clear whether we *want* to have such a "best of all worlds" 
   protocol, but the thread showed some interest on trying to come up 
   with something.  This also should be produced quickly.  Sign up if
   interested..

 - we could try to produce a draft on "procedures/considerations" 
   regarding how IPsec (+ NAT traversal) could be used for secure 
   IPv6-in-IPv4 tunneling, even with dynamic/private IPv4 addresses.  
   There are some issues to be fleshed out here, but probably no need 
   for protocol modifications.  It seems that it would be pretty 
   important to have at least a rough draft out soonish, to evaluate 
   the viability for e.g. the 3rd party tunnel or IPv6 VPN scenarios.
   Anyone interested..?  There's already one severely overloaded 
   person signed up, but we need more..

On mechanisms:
--------------

 - "Tunnel server management" (rather obvious) is something we should 
   be working on.

 - Teredo seems to be a rather strict requirement in the absence of 
   widespread support from ISPs.  However, there is concern about how 
   well it can be made to interoperate with native and 6to4 "clouds".

 - Deprecating 6to4 was suggested to simplify Teredo interactions, but 
   there has been quite a bit of pushback for this; some felt 
   in particular that 6to4 fulfilled an important role esp. when v4
   gateway is upgraded.

 - ISATAP is mainly interesting in "sparse" deployment case, which can 
   typically also be handled by a tunnel server.  On the other hand, 
   it has been proposased in "dense" deployment case as well, as a 
   means to avoid dual-stack deployment.  This is probably not where
   we want to go.  But this is still open.

 - A question was raised whether L2TP could fit the "tunnel server" 
   model.  It's relatively simple if the architecture is already in 
   place, but otherwise it may be too big a bother to set up.  So, 
   it's certainly going to be used, but whether it could be the only
   recommended solution for TB usage cases is another issue 
   altogether.

 - In the mechanisms analysis, we should try to figure out, somehow, 
   how to insert the "home gateway is doing the v6 tunneling" -case
   into the mechanism/scenarios evaluation.  Also, does it need 
   special consideration whether a mechanism gives you a /128, /64 or 
   /48 prefix?

On generic deployment issues:
-----------------------------

 - There were different views on whether we should be aiming for 
   wide-spread deployment ("for John Doe") or for some specific 
   interest groups (which could accummulate the critical mass for 
   "IPv6 demand elsewhere").  However, it seems unlikely that a killer 
   application would just appear before v6 *capability* has been 
   sufficiently widely deployed -- otherwise the app designers will 
   just stick to IPv4.  Further, the process is likely to take 
   multiple years at least, so we'd probably have to design the 
   deployment for the "general mass", even though we want to retire 
   the transition mechanisms (or at least some of them) when we get 
   there.

 - discovering the existence of 3rd party tunnel brokers is difficult 
   especially for non-technical people.  Whether automatic this 
   discovery is worth the effort is another question still.  (But 
   discovery of a local tunnel broker could be very useful.)

 - there are few incentives for ISPs to deploy tunnel broker service 
   to 3rd parties -- especially if the service would be free, 
   non-pilot -service, and would work well.  

 - app designers can't assume, except if they are designing apps to be 
   used in specific contexts only (e.g., enterprise networks) that 
   IPv6 addresses will be static in the longer term (e.g., 
   through reboots).

 - there was some debate on how much effort should be put to the case 
   where the user's ISP keeps changing the user's v4 address 
   "on-the-fly" intentionally.  Can we/should we work around that, 
   with realization that we're trying to "outsmart" the ISP who's 
   trying all it can to enforce some kind of service policy?

 - there was some debate on how often home gateways/NAT boxes are 
   being replaced.  I argued for the timespan of at least (about) 3+ 
   years, Jordi thought they would be changed much more often.  This 
   has an implication on whether we can get proto-41 support in the 
   boxes, or how quickly the users would switch their NAT box to one 
   supporting IPv6 if it was available.  It seems that unless there is 
   a strong killer app, this is dependent on the lifetime of the NAT 
   box, they are not replaced just for fun.

 - there seemed to be at least some agreement that at least the 3rd 
   party tunnel broker case was not particularly useful focus for 
   efforts.  

-END-