Re: The stupidity of trying to "fix" DHCPv6

13 Jun 2011

      On Jun 12, 2011, at 4:04 AM, Iljitsch van Beijnum wrote:
...
On 12 jun 2011, at 12:35, Daniel Roesen wrote:
...
Could you point to any RFC which implies or explicitly states that
DHCPv6 MUST NOT be used in absence of RA with M and/or O=1?
But what's the alternative? Always run DHCPv6 even if there are no router advertisements or router advertisements with O=0, M=0?
The alternative is as follows (can be done today without significant harm, only requires a couple of new
DHCPv6 options and trivial changes to host DHCPv6 implementations):

	Interface is initialized.
	IPv6 is initialized on the interface.
		Interface builds link-local address.
		Link local DAD is performed (Failure: Shut down IPv6 on interface... Done.)

		Look for static configuration. If Found, Apply static configuration, end.

		Initialize Backoff Timer = 3
		Initialize Tries = 0

LOOP A:
		Link Local->{All Routers,Link scope} Multicast ICMP RS packet is sent.
		Link Local->{All DHCP Servers, Link scope} Multicast DHCPv6 Solicit is sent
		Select(RA,DHCP while Backoff)
		Backoff*=1.5 if Backoff < 300
		tries++
		if (tries > 10 && !RA && !DHCP) Error, End

		repeat LOOP A if (!RA && !DHCP)

	if (RA)
			Process RA
			if (M || O)
			{
				if (DHCP)
				{
					Process DHCP as determined by {M,O} bits.
					End
				}
LOOP B:
				DHCPv6 Solicit (as in Loop A)

				tries++
				if (tries > 10 && !DHCP) Error, End

				repeat LOOP B if (!DHCP)

				process RA+DHCP according to M
				End
			}
	}

	if (DHCP)
	{
		# DHCP, but, no RA received
LOOP C:
		Router Solicit (as in Loop A)
		tries++
		repeat LOOP C if (tries < 5 && !RA)

		if (RA)
		{
			Process RA+DHCP according to {M,O} bits in RA.
		}
		else
		{
			Process DHCP as if RA received with no data and M bit
		}
	}
}
...
Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance.
I don't see how the above would do so. It's mostly compatible with what we have today and it would take a very very
large number of hosts (generally in excess of most switches forwarding table capacities) to contribute significant
network pollution.

Additionally, the multicast rate would only be increased on hosts which had no static configuration and the network
had no functional RA and/or DHCP services.
...
And networks without RAs are very common. We call those networks "IPv4-only networks".
Fair point. However, even in such a scenario, I don't believe that the traffic provided above (up to 20 multicast
packets provided over 422 seconds worst case) would constitute the kind of problem you are describing.
...
And in the current situation DHCPv6 without router advertisements is pointless because you may get an address, but you have no place to send your packets.
The point is that part of the solution needs to include adding routing information options to DHCPv6. That doesn't
even require significant modification to the DHCP software, just definitions for new fields and a little bit of UI
coding on the server and the ability to process the new options on the client.

Owen

Re: The stupidity of trying to "fix" DHCPv6

Owen DeLong