The stupidity of trying to "fix" DHCPv6
owen at delong.com
Sat Jun 11 04:12:26 UTC 2011
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
You must have RA to at least tell you:
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
> 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).
More information about the NANOG