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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
