[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

6Bone Mail

> From [email protected] Wed Sep 11 14:01:54 1996
>    > From: Francis Dupont <[email protected]>
>    > => 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).
> Regards
> [email protected]