Paul Jakma writes:
> On Fri, 4 Aug 2006, James Carlson wrote:
>
> > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt
>
> This draft has been superceded, version 6 was published as standards
> track RFC3633.
Yep; the list is stale. I'll update.
> I have an interest in this RFC, wrt supporting it for Quagga's RA
> sender-side code. (I've no idea though how one would manage interaction
> between such support in Quagga and with any existing system DHCPv6
> clients..).
Fortunately for me, the RA sender-side has nothing to do with this
project, as I'm implementing the client-side functionality. ;-}
I agree that there are some deep architectural problems with IPv6, and
that this issue -- entanglement of router discovery with addressing
policies -- is one exposure of those problems. Another is the
extremely strange 'R' bit in the Neighbor Advertisement message, which
ties together routing and NDP in not-completely-documented-or-
understood ways. (Perhaps that should just be IFF_ROUTER ... but even
that runs into trouble on hosts with virtual IP addresses.)
It's almost as if the protocol assumes a monolithic software
architecture. ;-}
Anyway, I would assume that if you're planning to put in server-side
code for RA, then you're also ripping out the server-side code that
already exists in in.ndpd and subsuming that functionality. If you're
not, then I'm not sure I see how Quagga will be reliable in such a
network. It seems like the two would be prone to conflict.
At the point where you're taking over RA functionality, I think that
means you also end up taking over the basic network configuration
broadcasting -- i.e., the setting of the 'M' and 'O' bits for the
network.
Other than simple commands ("set ipv6 stateful-addresses true"?) and
extensive user documentation (and risk of escalations when things fall
apart), I'm at a loss to see how to tie these things together
properly. It seems like it'd be best if the DHCPv6 server could
somehow "tell" Quagga whether it should say something about address
management. I don't know the right way to do that.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
