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

Pekka Savola radvd-devel-l@litech.org
Thu, 24 Jan 2002 23:05:48 +0200 (EET)

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 

> 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 

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 

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