Wed, 11 Sep 96 15:03:16 EDT
> From Francis.Dupont@inria.fr Wed Sep 11 14:01:54 1996
> > From: Francis Dupont <Francis.Dupont@inria.fr>
> > => there are three solutions for the dynamic routing of the 6 bone:
> > - RIPv6 but RIPv6 doesn't scale (remember DVMRP) and is not specified
> > for the usage over tunnels.
> How come? Why should RIPv6 work differently over tunnels?
> => it is not clear if a tunnel is an interface (with what kind
> of properties) and RIPv6 doesn't manage half connectivity.
> DVMRP is a distance vector routing protocol with special hooks
> for tunnel and is not the good solution for the Mbone.
> I believe we should avoid the same error...
A statuc tunnel is an interface with the same properties as any other
point-to-point interface/link. It has its own L2 encapsulation scheme, i.e.
IPv4 header (or IPv6 header for IPv6-in-IPv6 tunnels). That is all to it.
The RIPv6 problem that it does not manage half connectivity is not
confound to p-to-p/tunnel links. The same problem exists on broadcast
links -- e.g., you can have a bad Ethernet port that can transmit but
does not receive. ND's NUD can help somewhat here (yes, on tunnels too).
> As I see it, tunnel is just an instance of 'normal' point-to-point interface.
> => have tunnels link-local addresses (interface => link-local address
> according to RFCs) ?
They better have. My tunnels have.
>Are tunnels point-to-point or NBMA ?
Static tunnels are point-to-point. I guess you can play NBMA games
with tunnels too but I don't see any point in it except making things
much more complex than they ought to be.
> How the "multicast" is done on tunnels ? It is not so clear.
This is trivial -- there is only one recipient of multicast traffic
over a tunnel (the same as a broadcast link with only two stations attached).
> The fact that IPv6 packets are encapsulated into IPv4 frames at
> link layer should not matter at network layer. Do you tweak
> your network protocols for each meadia it may run over? I don't.
> => RIPv6 is specified for LANs (in the mind of its authors).
Not in the mind of a reader? :)
> Here at Bay we have a generic RIPv6 implementation which runs over tunnels
> as specified -- the same way it runs over other types of links.
> => do you detect half tunnels ?
We can use NUD for that. I aggree that is may not be a perfect solution
but as, I said, the problem is non confound to tunnels.
>Do you aggregate prefixes ?
If the routing policy say so? What is has to do with tunnels?
> RIPv6 is a cheap solution but I am not convinced it is the best
> today, NHRP is a good candidate too.
RIPv6 will be the most commonly avalable solution for dynamic IPv6 routing
in a short run.
> NHRP is not a routing protocol. Are you proposing to confine 6bone
> to a single LIS so no routing would be necessary?
> => yes because we have a global connectivity on the Internet
> then no intermediate routers are needed between clouds...
> We need NHRP for other NBMAs too.
This going to be one monstrous LIS :) It will not scale and the most
of all it is not needed.
> > PS: perhaps we should create a 6bone IETF WG or to resume the TACIT WG
> > (one of the T of TACIT are for "tests" :-) ?
> => I still think we need a WG for the future of 6bone
> (and not mix it with immediate operational issues).