[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits
While we are at this discussion, I need a few clarifications on how the deployments will get impacted. I've put forth my understanding on how things would be. Do correct me if I'm wrong.
1) Is there a way for a IPv6 client to distinguish between a authoritative RA vs non-authoritative RA? I guess not but I may be wrong. I refer to an unauthorized host sending out RA to be non-authoritative RA.
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.
3) RA-based address assignment is typically meant for scenarios over fewer subnets (like public hotspots/ISPs?) wherein requiring another infrastructure server (like DHCPv6 stateful server) will be a overkill.
Based on the above, it sounds better to NOT have M/O bit to control. They can act as a hint but 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? It would be rather obscure for a client to decide between misconfigured vs an unauthorized host sending RA.
Thanks
Kadir
-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf Of Pekka Savola
Sent: Tuesday, October 14, 2008 10:19 AM
To: Thomas Narten
Cc: DHC WG; IPV6 List Mailing
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits
On Mon, 13 Oct 2008, Thomas Narten wrote:
> 1) We could ignore/deprecate the M&O bits and simply have any
> client that implements DHCP invoke DHCP without even bothering to
> see what the M&O flags say. I.e, the way DHCPv4 works today.
>
> IMO, this approach would work fine. Indeed, it has the advantage
> that the client won't do the wrong thing due to misconfigured
> routers sending out M&O bits with the wrong setting. The main
> downside is that operators would have no way of signalling to
> clients that DHCP isn't available and they shouldn't waste
> resources trying to invoke it. In the past, there has been
> endless(?) debate about how significant the "waste" would be.
I don't see why M/O bits would need to be completely deprecated (they
could still be hints about what should be available in the network).
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. It's more complex to implement and to
operate reliably. But granted I haven't done an extensive survey; I'd
be interested in knowing how existing implementations operate.
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.
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's a lot of other junk
that hosts spew out anyway (e.g. some won't like similar Bonjour
multicasts). If this is truly a problem, we could try to figure out
solutions for that, e.g. by tweaking the retransmissions or giving
operational guidance for filtering in switches / access points.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg