Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits

[Iljitsch van Beijnum <iljitsch at muada.com>]

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 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------