[141897] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Jun 13 20:31:18 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <F6578C9E-02A4-4C55-95E1-823BC24A2CFE@muada.com>
Date: Mon, 13 Jun 2011 17:26:27 -0700
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: nanog@nanog.org, Daniel Roesen <dr@cluenet.de>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 12, 2011, at 4:04 AM, Iljitsch van Beijnum wrote:
> On 12 jun 2011, at 12:35, Daniel Roesen wrote:
>=20
>> 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=3D1?
>=20
> But what's the alternative? Always run DHCPv6 even if there are no =
router advertisements or router advertisements with O=3D0, M=3D0?
>=20
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 =3D 3
Initialize Tries =3D 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*=3D1.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
}
}
}
=09
> Like I said before, that would pollute the network with many =
multicasts which can seriously degrade wifi performance.
>=20
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".
>=20
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
