RFC1897 & more tunels

[Alain Durand]

The question now is how to grow from a 3 nodes 6-bone
to a 10 or 15 nodes 6-bone

Basicaly I see 3 solutions for the very short term

1) an n to n topology. Each node maintains routing tables to the other nodes.
This is what we agreed on at last 6-bone meeting in Montreal. This just won't
scale very well.

2) a star topology. Only the central node has to maintain all routes,
the other just need a default route to it. The drawback is that scheme
create a single point of failure.

3) a mix of the 2 solutions.

In france, the G6-bone is made of 3 islands and will grow to 5 or 6 by the end
of the year. We agreed on a star topology inside the G6-bone with a central
node at imag
(129.88.30.1, 6bone-gw.ipv6.imag.fr, 5f06:b500:8158:1a00:1:0:8158:1a01)

What could be a solution will be to have a small number of core 6-bone nodes
will a complete knowledge of the other core nodes. Typically one for each
country. Then, other folks willing to join will just have to tunnel to the
closest core 6-bone node.

This is not as simple as it sounds. The problem is with the routing
tables. We do not want to manage hundreds of static routes.
The issue is RFC897. It specifies that the address is 5f + ASnumber of the
IPv4 provider + ipv4 address of the network.
This is simple and does not require any registry. But maybe it's too simple.
We can not easily agregate routes that are not for the same AS,
and inside an AS, we can not agregate routes for differents
ipv4 networks that belong to the same institute.

Let me take two examples:

a) inside the G6-bone, we have an island at INRIA. They use 2 ipv4 networks
with very differents numbers. I need two different routes for them.

b) inside the 6-bone. I have asked people to route 5f06:b500::/32 to my
entry point. Fine till now. But if someone inside G6 has a different ISP
tham mine, this will not work anymore.

So maybe it's time to revisit RFC1897.

RFC1897 states:

   | 3 |  5 bits  |  16 bits | 8 |   24 bits  | 8 | 16 bits|48 bits|
   +---+----------+----------+---+------------+---+--------+-------+
   |   |          |Autonomous|   |    IPv4    |   | Subnet | Intf. |
   |010|  11111   |  System  |RES|   Network  |RES|        |       |
   |   |          |  Number  |   |   Address  |   | Address|  ID   |
   +---+----------+----------+---+------------+---+--------+-------+


maybe something more suitable will be:

   | 3 |  5 bits  | 8bits| 16 bits  | 8bits |  24 bits  | 16 bits|48 bits|
   +---+----------+------+----------+-------+-----------+--------+-------+
   |   |          |      |Autonomous|IPv6   |    IPv4   | Subnet | Intf. |
   |010|  11111   |6-bone|  System  |Island |Network    |        |       |
   |   |          |node  |  Number  |Number |  Address  | Address|  ID   |
   +---+----------+-----------------+-------------------+--------+-------+

The "6 bone node" will then be a number attributed to a core 6-bone node.
As there will be very few core 6-bone node, this will be managable.

Then, inside each island, we can attribute island numbers.

Using this scheme, routing table will be very simple.
The n core 6-bone nodes will only need n-1 "external" routes
and m (the number of internal island) "internal" routes.


Then as Jim said, we also need an algorithm to find the ipv4 address
of a tunnel endpoint from it's ipv6 address.
I have a suggestion:
assign a special ipv6 global address for the tunnel endpoint and
put the ipv4 address of the encapsulating interface into the last 32 bits.

Example, my tunnel IPv4 address is: 129.88.26.1 (= 8158:1a01 hexa)
It's IPv6 address is 6bone-gw.ipv6.imag.fr: 5f06:b500:8158:1a00:1:0:8158:1a01
according to RFC1897 and could be 5f01:06b5:0181:581a:0001:0000:8158:1a01
	-> 6-bone node 1
	-> AS 06b5
	-> island number 1
	-> ipv4 network address: 81:581a
	-> subnet address: 0001
	-> interface: 0000:8158:1a01 -> ipv4 tunnel interface 129.88.26.1
according to the scheme I propose.


	- Alain.



-- 
                                                                        ^_^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   U  (* *)
Alain DURAND                       |  Preserve keyboards:           |  ( v )
I.M.A.G.                           |     use completion.            |  /~~~\
Direction des Moyens Informatiques |-----------------------------  <|=< IP  >=
BP 53 38041 Grenoble Cedex 9       | E-Mail: Alain.Durand@imag.fr   |  \ v6/
France                             | Phone: +33 76 63 57 03         |   <~~<
Postmaster@imag.fr                 | Fax:   +33 76 51 49 64            ~   ~