[Int-area] Re: Architectural reasons why tunnelling is an indication of a failure

[Pekka Nikander <[e-mail]>]

Brief summary of the discussion so far:
---------------------------------------

I made the claim that tunnelling, while being sometimes (but not  
always) a fine tool, is an indication that the architecture has  
shortcomings, and therefore has "failed" in some sense of the word.   
[Apparently the word "failure" was too strong, but at least it  
generated some discussion :-)]

A number of people replied that tunnels are a useful tool for  
virtualising the address space, similar to virtual memory in von  
Neuman architecture.  One could claim it even to be similar to  
virtual machines.

Clarifications on my side:
--------------------------

I am definitely not saying that tunnelling is bad and that we should  
ban it; quite converse.  As several people mentioned it is a fine  
tool, often allowing much faster evolution and often leading to  
easier operations.

What I am trying to do is to understand the pressures that lead to  
the currently very common use of tunnelling (with its apparent more  
technical problems).  One way to express my feeling is the  
following:  I think that we should not need tunnelling; i.e., our  
architecture should be powerful enough so that (most current) needs  
of tunnelling would disappear.

In this message I am still trying to argue in favour of my position  
that tunnelling is an indication of something missing, mainly  
pointing out that there are alternatives to virtualisation, both in  
computer and network architecture.

If we can go further and try to understand the alternatives and there  
potential implications, that would be even better.

Going further:
--------------

I think comparing tunnelling to VM is a good analogy, and certainly  
something that I missed in my original thinking.  [Thanks to  
everybody that pointed it out.]  However, I also think that we are  
not doing a very good job there.

I am framing my argumentation below as follows:

1. There are architectural alternatives to today's virtual memory.
2. Virtual machine is more than virtual memory.
3. None of our current tunnelling practises come even close to the  
level of abstraction provided by either the virtual memory or virtual  
machine abstractions.
4. Even if we may get a clean virtualisation architecture with IPv6,  
we are not there yet, and may not be clear where, exactly, we should  
be going.

Details:

1. Architectural alternatives to virtual memory
===============================================

If we think about today's virtual memory systems it consist of two  
apparent mechanisms that seem to be orthogonal:

  a. Mapping virtual addresses to (different) real addresses
  b. Protection bits, providing lots of functionality

If we consider address mapping first, there are certainly  
architectural alternatives.  For example, if you have a large enough  
address space, you could use position independent code.  With proper  
support at the processor level that can be done as convenient as  
virtual-memory-based mapping.  The amount of hardware needed is  
basically the same; the difference is on the abstraction.

I am not going to the protection part.  It is apparently a very  
useful abstraction, providing lots of useful functionality such as  
copy-on-write, flush-on-dirty, etc.

The point is that even a good virtualisation abstraction seems to  
consist of several components, some of which don't _necessarily_  
imply others.

2. Virtual machine is more than virtual memory
==============================================

The majority of today's hardware does not support full virtual  
machine functionality, i.e., virtualising also the protected mode.   
In the main stream architectures it has been appearing only  
recently.  Consequently, many of today's virtual machine products  
either use software to "cheat", resulting in architecturally ugly  
(but useful!) solutions, or are fully implemented in software, with  
the apparent performance penalty.

My point here is full virtualisation, such as in the case of virtual  
machine, requires much more than just virtualising the address space.

3. Our current tunnelling practises are not very clean
======================================================

Returning now to the current IP-over-IP tunnelling practises (which  
seem to be closest to virtualisation), I claim we could do much better.

The first issue, which I already touched, relates to muddled address  
space semantics.  While one could argue that RFC 1918 addresses are  
like the virtual address space in a virtual memory system, that  
AFAICT doesn't quite hold.  The difference lies in how you  
communicate with components outside of that virtual space.

Having a very large address space with no overlapping addresses seems  
to lead to a cleaner architecture than mapping address spaces.  For  
us, going to IPv6, Unique Local IPv6 addresses (draft-ietf-ipv6- 
unique-local-addr-XX.txt; sometimes called Hinden-Haberman addresses)  
may help.

If you go there and get rid of RFC 1918 addresses, returning to  
addresses that are globally unique, what remains is the question of  
routing.  For practical reasons, it looks like that people may need  
to use tunnelling even for Unique Local IPv6 addresses.  The reason  
for this is that the routing system does not easily allow them to be  
globally routable, which, in turn, leads to another architectural  
question:

   Should the routing system better support local-only routes?

[There are lots of potential answers to both the narrower practical  
question and to the larger architectural one; e.g. use MPLS, use  
source routing, etc., but that is not the point of this message.  The  
point here is that the fact that tunnelling is needed may, again, be  
an indication that some functionality is missing elsewhere, in this  
case in routing.]


A second (perhaps converse) issue here relates to layering.  Some  
people expressed their belief that IP is such a useful service that  
building virtual topologies over an existing one is beneficial.   
Certainly so, but my question is now much of this is caused by  
current architecture, i.e., the fact that IP addresses are  
simultaneously used as identifiers and locators.  If these two roles  
were separated (most probably leading to two having (sub)layers  
instead of the currently one IP layer), what would that virtual  
topology bring?

My claim is that if we did the split, there would be much less need  
for "managing" the IP address space, leading to a situation where  
most (if not all) long term needs for IP virtualisation would disappear.

4. Full virtualisation for IPv6
===============================

A major question now appears to be what we should do about IPv6 and  
tunnelling?  Based on the discussion to far it appears to me that it  
may be a good idea to try to figure out a full virtualisation  
architecture for IPv6, i.e, one resembling virtual machines (instead  
of virtual memory).  That leads to a number of more practical questions:

- Who would need it?
- What would be the requirements that it would fulfil?
   - e.g. what do people need topology abstraction for?
   - what level of emulation are we expecting
- What is missing (if anything) in the current solutions we have?

Maybe all we need is a BCP explaining how to use existing components  
in the best possible way for virtualising IPv6 in a local network,  
with appropriate barriers between the local and outside world?

But before that I'd like to here what are the real benefits that  
people would expect to get from it, as I am personally having hard  
time seeing them.

--Pekka


_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area