[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 5006 status
In your letter dated Thu, 18 Mar 2010 12:39:14 +0100 you wrote:
>Philip Homburg <pch-v6ops@u-1.phicoh.com>, 2010-03-18 10:38 (+0100):
>
>> From an implementors point of view, the main thing I find annoying
>> about RFC-5006 is that information about DNS servers ends up in the
>> kernel instead of in user land where I need it. And I don't want the
>> kernel to store and forward all kinds of user land data.
>
>No client side implementation of RFC 5006 that I know of is done in a
>kernel. I guess I don't understand what you mean.
Let's assume that I want DUD to start as soon as possible, so my kernel
sends the first router solication as soon as the ethernet link is up.
Then it may very well be that the kernel receives an RA before the user
land DNS configuration program is running. Then the DNS option in the RA will
be lost.
So, the DNS configuration program has to send its own router solication. If
DNS configuration data is actually distributed using DHCP, then we just wasted
a multicast and interrupted all routers on the link.
Solution, have the kernel store this information.
Of course, we can pay attention to the other configuration bit in the RA,
and have the kernel store that bit. Then, when that bit is set, we can try
DHCP first and if that fails to return DNS servers fall back to sending a
router solication. Possible, but annoying.