[6bone] link local for tunnel endpoints

[Pekka Savola]

On Sat, 8 Nov 2003, Jun-ichiro itojun Hagino wrote:
> > Rather silly use of route6d, if you ask me.  Just ask the ISP to configure 
> > fe80::1 as the address, or find the address of the neighbor otherwise 
> 
> 	it is not a silly use of route6d (RIPng).  it is a legitimate usage.
> 	global address is not required on p2p links operationally.

Right, you don't need a global address, and it's probably not useful to 
have it in e.g. home customer scenarios.
 
> 	pros and cons of this approach:
> 	+ customer router need not to know the link-local address of the
> 	  upstream router (or upstream router device change)

True, but if the tunnel is point-to-point, it may not be necessary to 
even know that.. (as Gert pointed out)

(For example, in Red Hat Linux (when in Router mode), you only have to do
"IPV6_DEFAULTDEV=sit1"  and you're done.  You'll have to use
IPV6_DEFAULTGW=xxxx" otherwise.  You can use only defaultdev with
point-to-point tunnels.)

> 	+ upstream router can know the liveness of the link easily by looking
> 	  at routing table (with tunnel link, it is hard to know if the tunnel
> 	  path is live or not - no carrier signal like other p2p link)

True; an alternative and a common way to do it is to ping the router at 
some intervals.

> 	- ISPs are still afraid of running dynamic routing daemon on customer
> 	  link (RIPng filtering should be sufficient, but...)

I can certainly appreciate this fear, and I think it's a valid one as 
well.  Sharing a process space with N (N >> 1) customers even with 
filtering is scary.  An implementation problem and you may experience a 
lot of problems..

> > (e.g., it can be calculated for v6-over-v4 tunnels by yourself).
> 
> 	this forum is not for standardization, anyways, i'll keep continue...
> 
> 	only if RFC2893 seciton 3.7 is followed by the upstream router.
> 	RFC1933 does not have any requirement for link-local address.
> 	kame implementation computes link-local address for p2p links by using
> 	RFC2472 4.1.  (i.e. KAME's tunnel interface is RFC1933 implementation)
> 
> 	btw, i do not think RFC2893 section 3.7 is necessary.  either
> 	it is up to implementer, and RFC2472 4.1 is superior (so if we define
> 	some standard way just refer RFC2472 4.1).

Could you please send this to v6ops, so that it can be considered, now 
that transmech is being revised?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings