[radvd-devel-l] Advertising interface is not "autoconfigured"

[Pekka Savola]

On Thu, 24 Jan 2002, Venkata Jagana wrote:
> According to RFC 2462, the autoconfiguration process specified
> in this doc is applied to hosts but not routers and however,
> there is nothing that says router interfaces can't be autoconfigured.

How is a router defined?  IMO, in RFC 2462 context, a node is a router in 
interface X if it is advertising, or capable of advertising, on interface 
X.

> If they should't be autoconfigured then in manual configuration, what
> prefixes would be used to configure those interfaces. Wouldn't they
> be same as the prefixes advertised by radvd on the respective interfaces?

One could always use PREFIX::1 and the like.

Note that I'm not saying an absolute no on 'radvd' capability to add 
PREFIX::EUI64 address on the interface when the interface is active.  But 
I don't like the idea of receiving the "local" advertisements on the 
interface.

What do others think, would this be useful?  [if yes, patches?]

> In fact, I believe (based on old email on this topic on netdev) the
> KAME stack doesn't seem to even accept or autoconfigure addresses for
> router interfaces based on RA's received from other routers. 

KAME -- accept yes, autoconfigure, no.  This should be how these are 
handled; even accepting could be removed, though.

> But that's
> not the case in radvd for Linux either. Radvd daemon on Linux is
> disallowing autoconfigration with the advts from the same router but
> not from other routers if forwarding is enabled and I believe this is
> inconsistent. 

radvd should accept them (print inconsistancies with advertisements etc.) 
but definitely not autoconfigure from them.

Whole RA processing could be removed, but it might help in debugging 
situations.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords