Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-04.txt

From: Richard Draves <[email-masked]>
Date: Fri, 11 Jun 1999 10:56:36 -0700

> If you run ripng (and perhaps other routing protocols) over these
> tunnels you must have a link-local address since the ripng spec
> mandates their use as source addresses.

Is anyone running ripng over configured tunnels in the 6bone? Or is it all
BGP4+? Does BGP4+ need link-local addresses? I've never run a dynamic
routing protocol over a configured tunnel so I haven't run into these issues
and I've not seen link-local addresses used with unidirectional configured
tunnels.

> What is the difference in terms of implementing and/or configuring the
> pair vs. the bidirectional one?

The key difference is the use of ND. If one endpoint is expecting to use ND
and the other side does not support it, communication will fail. Currently I
believe (correct me if I'm wrong please!) that ND is not used over any of
the 6bone's configured tunnels.

Rich

---

From: [email-masked]
Date: Sat, 12 Jun 1999 14:39:33 +0900

>and I've not seen link-local addresses used with unidirectional configured

	We run ripng and bgp4+ over many of our tunnels.  for bgp4+ I believe
	we are using global addresses (we must check).

itojun

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Jun 1999 14:24:23 +0200

> mandates their use as source addresses.
   
   Is anyone running ripng over configured tunnels in the 6bone?

=> you can have tunnels inside your local infrastructure or believe
RIPng is suitable for inter-domain routing (:-). RIPng sees only
local things then knows only link-local addresses (peers / next hops
share a link). In fact before RIPng all the tunnels have no link-local
addresses and don't use Neighbor Discovery...

   Or is it all BGP4+? Does BGP4+ need link-local addresses?

=> it is a complex issue. At the first view BGP4+ needs only global
addresses but this is not true then there is a document (RFC 2545)
about these problems (connected routes, iBGP/eBGP, interaction with
RIPng, third parties, ...). The exact statement is:
   The link-local address shall be included in the Next Hop field if and
   only if the BGP speaker shares a common subnet with the entity
   identified by the global IPv6 address carried in the Network Address
   of Next Hop field and the peer the route is being advertised to.
Then the real answer is BGP4+ may need link-local addresses then
you MUST set link-local addresses for tunnels between two border routers
on the 6bone (a case where in general that statement applis).

   I've never run a dynamic
   
=> it is easy to verify if BGP4+ over 6bone tunnels adds link-local
addresses in next hop field of multi protocol attributes. Would you
like to collect answers about this point?

   
=> obviously the only ND you should get on configured tunnels are NS/NA
exchanges for NUD then there is a third solution (other than to implement
full ND or not to implement ND): never send a NS but answer to a NS by a NA.
I have implemented this because some routers sent NSs with stupid link-layer
stuff then a minimal support is needed (and easy to provide)...

Regards

[email-masked]

PS: I'd like to get *precise* statements about all these issues
(for instance the must for link-local addresses is a must, not a MUST).

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Jun 1999 11:02:30 -0700 (PDT)

> the 6bone's configured tunnels.

There must be some miscommunication. I added the whole concept
of bidirectional tunnels in the draft because you pointed out
that the concept was missing. And now you want yet-another concept!

  Erik