On Jun 10, 2011, at 8:36 PM, Matthew Reath wrote:
This is "different types of networks and network users" and also different operational, administrative, and security domains.
I am also getting frustrated with the endless discussions that could be immediately shortened by "tinkering with DHCP" to add one or two additional options -- a minimal cost process. Why is the argument not about business needs instead of technical purity?
I'd have to agree with this. Although from a technical standpoint RA Guard would be a plausible solution to the rogue RA problem. However, the bigger issue seems to be the mixing of what used to be managed by different groups. Now you have IP transport folks implementing parameters sent to client machines or routers. Less than ideal probably.
What are the current options for a company to disable RA messages, implement RAGuard, and force clients/routers to use DHCPv6 or static assignment for IPv6 addresses? I believe ignoring M and O bits would break standard though - but what if they never get sent?
Currently, you cannot disable RA unless you want to statically configure EVERYTHING. You must have RA to at least tell you: Default Router Go ask the DHCP server (M and/or O bit) As it currently stands, an RFC-compliant host will not attempt to solicit a DHCP response unless it receives an RA with the M inclusive-or O bits set.
I know on Cisco you can suppress the RA, but not sure if you can force most clients to make DHCPv6 requests instead of listen for RAs.
You cannot. You also cannot (as it currently stands) get DHCP to issue prefix length information (other than through PD which is different and not what most hosts will ask for) or routing information (default or a series of static routes). This is why we need the following: 1. Add options to DHCPv6 for routing configuration 2. Add the ability to have site-defined and/or vendor-speciic options to DHCPv6 if it hasn't been added yet (I'm not sure of the current state on this one). 3. Add options to DHCPv6 to specify prefix information, including prefix length. These are light-weight adds to the DHCP specification that can be very easily implemented by DHCP server producers. Hosts would also need to be modified as follows: 1. If the M bit is set or no RA was received, the host should only use the RA default gateway if there is no routing information in the DHCPv6 options. This would require updates to the DHCP client and possibly the parts of the OS that handle RA route installation. Also relatively simple modifications and probably easy to get into the OS relatively quickly once documented. In addition, it is _VERY_ desirable to modify the host autoconfiguration specification going forward to require hosts to: 1. Solicit an RA (as they do now). 2. Solicit DHCP (immediately, without waiting for an RA with the M or O bit). 3. Wait <t> seconds for RA to come back. 4. If RA received, process it appropriately and finish the DHCP transaction if specified (M and/or O bit in RA). <END> 5. If no RA received, complete the DHCP transaction as if an empty RA with the M bit set was received. <END> While it will take a year or so for this to start making its way into boot-ROM firmware and such, and, another 3-5 years of technology refresh for that to become the PXE default behavior, it will actually make it into OS updates much faster and that covers the majority of dynamically addressed systems anyway. Note, in the meantime, sites that don't want to use RA can limp along with the existing process by providing DHCPv6 configuration information and essentially empty RAs with the M bit set (once host modification 1 in the previous list is implemented). Owen