Hi Jim, On Mon, 7 Aug 2006, James Carlson wrote:
Fortunately for me, the RA sender-side has nothing to do with this project, as I'm implementing the client-side functionality. ;-}
:) Just to stress, none of this is any immediate obstacle to DHCPv6, but its worth having a quick think about it at least.
I agree that there are some deep architectural problems with IPv6, and that this issue -- entanglement of router discovery with addressing policies
Yeah, the whole collision of DHCP an RA in IPv6 is annoying actually.
-- 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.
To allow prompt detection of routers that stop being routers, according to the RFC ;).
It's almost as if the protocol assumes a monolithic software architecture. ;-}
Where ever would such an assumption come from? :)
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.
That'd seem the right thing to do, in such a case.
Other than simple commands ("set ipv6 stateful-addresses true"?) and extensive user documentation (and risk of escalations when things fall apart),
Yes, it has such commands, to control M and O in RAs sent.
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.
Well the worry is, I guess, given how that RFC throws together DHCP server, client and RA sender (for the requesting router at least), how to make them play nice together. Which isn't a question we can answer here, is it?
Actually, maybe there's a deeper question here generally of various routing and addressing services generally being unaware of each other, not always blissfully (and, it seems, ever less blissfully with time as new technologies/requirements/user-expectations come along).
regards, -- Paul Jakma, Network Approachability, KISS. Sun Microsystems, Dublin, Ireland. http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190 _______________________________________________ networking-discuss mailing list [email protected]
