Iljitsch van Beijnum <[EMAIL PROTECTED]> writes:
> On 13 okt 2008, at 18:19, Iljitsch van Beijnum wrote:
> > I don't have any use for DHCPv6. I need a way to shut up DHCPv6
> > clients that may end up visiting my network. Running DHCPv6 in a
> > network that doesn't support is is especially harmful because there
> > will be lots of retransmissions, which are multicasts that use up a
> > lot of airtime on wifi networks.
> This probably wasn't very clear. What I mean is the situation where
> clients would be initiating DHCPv6 but there are no DHCPv6 servers.
My understanding is that when clients invoke DHC, and there are no
DHCP servers, they backoff and retransmit, eventually stablizing as is
governed by the following (from RFC 3315):
MRT specifies an upper bound on the value of RT (disregarding the
randomization added by the use of RAND). If MRT has a value of 0,
there is no upper limit on the value of RT. Otherwise:
if (RT > MRT)
RT = MRT + RAND*MRT
In the case of solicit messages, MRT is set to 120 seconds. RAND is
set to +/- .1, so the RT is capped at between 118 and 122 seconds.
So, clients will retransmit about once every 2 minutes.
> This is unnecessary multicast traffic that could easily affect wifi
> performance because on 802.11 multicasts are generally sent at the
> lowest supported speed.
But let's not forget, Neighbor Discovery also uses IP multicast. So,
if multicasts are problematical they are probably already
problematical just for ND. Right?
Has any analysis been done to show how much *additional* load would be
created by DHCP multicasts above and beyond basic multicast needed for
IPv6?
Finally, can you further explain what you mean by "affect
performance"? If there are no DHCP servers present, it doesn't matter
much if all the clients are sending multicasts using the lowest speed,
since no one is listening. Right?
So, before I'd agree with the notion that the additonal multicast
affects performance in practice, I'd like some explanation/analysis.
> Routers have been supporting the setting of the M and O bits for ages
> so it's no trouble setting those if DHCPv6 is desired, so there is no
> real downside to limiting the use of DHCPv6 to the situation where at
> least one of these bits is present in router advertisements from at
> least one router. (It would even be possible to generate RAs with a 0
> lifetime with M/O set for this purpose, hosts won't create a default
> route for those RAs.)
Did you read my original note carefully? In it, I pointed out that one
concern against trusting the M&O bits was misconfiguration. You may
think this scenario is rare to non-existant, but please acknowledge
that others in the community may view the concern differently than you
-- and indeed, may weigh this concern as more significant than your
concern about additional multicast traffic.
> A corner case is the situation where there are no routers, but I don't
> see how having a DHCPv6 server in that case still makes sense (would
> it even work?), communication can and probably should happen over link
> locals in this case.
Sure. In an ad hoc situation, I could set up an DHCP server (and DNS
server) just to serve the local ad-hoc network. No routers present,
just me and my ad hoc friends.
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
