Subject: Re: v6 question
To: Robert Elz <kre@munnari.OZ.AU>
From: None <firstname.lastname@example.org>
Date: 02/14/2000 11:52:35
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.