is this the right place for this discussion? :-P

>  | 	RFC2462 page 8 has the following sentence:
>Yes, but that's talking only about the mechanisms in 2462.

	It's in protocol overview section and there's no explicit mention
	that this is only about mechanisms (correct me if I'm wrong).

>  | 	As long as we obey RFC2462, we can't autoconfigure routers.
>No, that's an incorrect conclusion.   You can autoconfigure routers
>and not conflict with it in the slightest.   What doesn't make sense
>is to use the 2462 mechanisms (or at least, only those mechanisms) and
>pretend to be autoconfiguring a router.

	If you have only one external interface on the router (which does not
	look very useful situation for me), I think I can autoconfigure router
	with RFC2462.  Otherwise, I think there are conflicts.

	Please let me know how you would handle autoconfigured default
	router list on a router?  When the router accept RAs from multiple
	interface, what would you do?  Simply ignore them?  Install the last
	one we've heard?  Others?
	Also, accepting RA from the router itself (which was the topic we
	started this thread) is very strange, since
	- we only advertise RAs to downstream
	- interfaces on autoconfigured hosts (nodes if you want to call)
	  supposed to point upstream
	- and the interface on the router is directed toward downstream

	I still believe RFC2462 assumes the following:
	- the box to be autoconfigured is a host, not a router
	- the host has only single external interface
	Without these two assumptions, there are couple of holes in the
	document (which I'll be happy to see clarifications).

>A new doc, yes - that will be needed, though whether the doc comes
>first, or someone tries writing the code first, and documents it
>after it works (or at least a prototype works) is not so important.

	Yup, KAME side was not really interested in autoconfiguring routers,
	either.  We did have some discussions on it, and postponed it
	because of too many twists in it.  We have to many code to tackle.

	Router renumbering is one of compromises we have now (it assumes that
	valid subnet numbers are already in place - this decrease the
	difficulty very much).  For security reasons (requires IPsec over
	site-local multicast to be secure) it is not enabled in NetBSD.

itojun