On 14 okt 2008, at 9:10, Kadirvel Chockalingam Vanniarajan wrote:
1) Is there a way for a IPv6 client to distinguish between a authoritative RA vs non-authoritative RA?
What are those?
2) In an enterprise-level deployments, IPv6 deployments will typically happen on top of existing subnet segmentation which was driven by IPv4 subnet logistics. If this being the case, expecting RA to be configured by the network administrator on each one of the routers sounds to be a management nightmare.
They need the routers to send RAs with prefixes that match what the DHCPv6 servers will be using to give out addresses from so coordination is necessary anyway. At the time these prefixes are set up the bits can be set up as well. No additional nightmare.
how well a client can make a decision based on the hint if it cannot say for sure if the RA received is from some authoritative router or not?
An enterprise already has to handle unauthorized RAs, those are harmful in many other ways. (As anyone who received 2002::/16 addresses during an IETF meeting can attest to.)
But in this case there is no issue if MO != 00 in ONE RA out of the RAs sent by all routers means that DHCPv6 will be initiated. So if the correct RA goes out it doesn't matter how many additional incorrect ones there are.
I've yet to see a DHCPv6 client implementation that would listen to the flags in RA and conditionally start or stop the service depending of the presence of flags there.
Apart from Vista and special cases such as Cisco routers I'm not aware of an integrated DHCPv6 solution; they are all standalone programs that run when you run them and don't run otherwise. So there must be an administrative decision to run a DHCPv6 client.
So I believe we're kidding ourselves if we think the DHCPv6 client software writers and operating system SW engineers trying to figure out a most reliable way to use DHCPv6 wouldn't start DHCPv6 client automatically under every scenario, no matter the flags. These implementations are not going to change no matter what we write in the RFCs.
Disagree. I've personally seen DHCPv6 struggle to get where it is today over the past 5 years. It has been slow going with many mistakes along the way. I don't think there is any reason to assume we've reached the end state today.
Over time, implementers usually refine their stuff to be more compliant. So specifying the correct behavior is a good thing even if we don't know for sure implementers are going to turn on a dime and implement it overnight.
I don't believe the concern about wasting 802.11 airtime or other bandwidth is severe enough in those peoples' (or my) mind that it would justify the necessary complexity.
There is no complexity. It's just work.
If this is truly a problem, we could try to figure out solutions for that, e.g. by tweaking the retransmissions
THAT would be complexity. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
