Subject: Re: (ngtrans) <draft-many-ngtrans-connect-ipv6-igp-00.txt>

From: Gilles Diribarne <[email-masked]>
Date: Wed, 05 Sep 2001 15:52:17 +0200

> The draft only addresses the mechanism for transporting tunnel endpoint
  > information (other stuff left to be implementation-specific).
We consider that the draft shouldn't cover this point, since
  > Is it specified how the tunnels themselves are built using this
knowledge?

We consider the draft shouldn't cover this point, since implementations
are different for all routers.

  > And routes added pointing to them as nexthop?  Security considerations?
A solution could be to install new routes into OSPFv3, using an
implementation specific method. These route are then distributed by
OSPFv3 to other routers in the islands, as for all the prefix.
If you think it is interesting to add this information, why not !

The security uses native OSPF mechanism, since we propagate Opaque-LSA.
Can you tell what problem you see with security, that is not covered by
OSPF?

  > OSPFv3 is not really deployed at all yet -- won't be for some time yet.
  > There is about one relevant implementation.
  >
  > Somehow I'm a bit of sceptic on how adding more complexity like this
  > really reduces any real transitionary pains.  Is setting up tunnels
really
  > all that difficult -- sure if you want a full mesh between all IPv6
  > routers in a big corporation, this might be useful, but often it makes
  > sense to design the network differently.

Imagine your network. At the beginning, you've only two routers
IPv4/IPv6 and you connect it with a ship-in-the-night method. But, it
evolves and you buy five dual stack routers. Now, you've to establish a
lot of configured tunnels to maintain the communication between us.
Moreover, maybe the tunnel you configured the first time is not the
best way in this new situation. So, you've to create different
tunnel and each time, think to your network configuration. We propose a
dynamic tunnel configuration, using all the time the "best way".
Also, we thought, indeed, about a big corporation network.

  > In short, I'd like to hear whether others think this is really needed or
  > is it just "because we can". :-)
  >
  > Of course, all of these transitionary techniques really depend on the
fact
  > on how long we think the transition is going to be (in organization
scope)
  > and when it's going to start...

We can do it and it is interesting to do it :-)
And it is interesting because you don't have to preoccupate of tunnel
configuration. We suppose that automatic tunneling will be used, as same
as BGP-tunnel method (it could be any kind of address, such as
IPv4-compatible if it exists in future, IPv4-mapped address, etc.)
The configuration of this opaque could be one line in a configuration
file: "ipv6 enable-connecting-island :ffff:192.196.10.1"

At the beginning, you will have some IPv6 islands, and at the end,
you'll have remaining IPv4 islands. Our method proposes a way to have a
smooth transition. At the beginning, you will need to carry V6 prefixes
over V4 network. At the end, you will need to carry V4 prefixes over V6
network, for the remaining V4 networks. Our solution could be applied
for both transition system, since the opaque-LSA can carry any kind of
prefixes.
Well, it is our little vision of the future transition in an
organisation. It is sure that organisations won't move directly to a
IPv6 solution and we need to ensure it will be easy for them.

Gilles,
ALCATEL

---

From: Alain Durand <[email-masked]>
Date: Wed, 05 Sep 2001 10:43:15 -0700

> Also, we thought, indeed, about a big corporation network.

I have been looking at this problem in a very large corporation
(you can easily imaginge which one). In that particular case,
there are plenty of IPv4 addresses (maybe not enough,
but at least a bunch per site)
I found that 6to4 was a very interesting mechanism with
very good scaling properties. Anytime I want to connect a
network/site to my internal IPv6 cloud, I add an extra 6to4 router.
Doing this has interesting internal security properties,
gratuity of the underlying IPv4 security/firewalling/filtering...

    - Alain.

---

From: Alain Durand <[email-masked]>
Date: Wed, 05 Sep 2001 10:53:39 -0700

Stepping back a little, we now have 2 set of proposals to address the
issue of scaling tunnel set-up during transition.

a) 6to4 + isatap
b) BGP-tunnel + connect-ipv6-igp

As work in the general direction of a) has started long time ago and is well
on its way, I would like to suggest the authors of b) to come up with some
rationale/applicability statements that would help the working group
to understand better how to position b) in regards to a)

    - Alain.