On 13 okt 2008, at 22:59, Thomas Narten wrote:
So, clients will retransmit about once every 2 minutes.
But they'll transmit packets more frequently initially.
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?
It's not a question of "problematic yes/no". More multicasts means
less performance for other stuff. Obviously ARP and ND already
generate multicasts, as do various discovery systems such as netbios
and multicast DNS. I believe this is an important reason why 802.11g
performance in the plenaries during IETF meetings is so bad, but I
don't have hard figures to support this.
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?
???
The problem is that the multicasts take up large amounts of airtime so
they get in the way of other traffic; whether someone is listening
doesn't matter. In the case where there is a DHCPv6 server there will
be one multicast from the client (I believe the server replies with a
unicast but I could be mistaken), but in the case where there is no
server the client will be retransmitting so this means more traffic.
On big wlans this could lead to the perverse situation that people may
need to run a DHCPv6 server just to get rid of the traffic if there is
no other way to shut the DHCP clients up. Which there of course is and
has been for a very long time in the form of the M/O bits.
Implementation difficulties mentioned by others fail to convince me.
Address configuration is something that needs to be fairly intimate
with a number of system functions, so if DHCPv6 takes off this will
undoubtedly happen in the OS like DHCPv4 is usually done today and
this isn't an issue. Opening a raw socket and listening for RAs is
also a possibility. It's not like sending out packets with the
unspecified address is a standard call; DHCP implementations need to
be close to the network anyway.
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.
Where in the community? There was a mention of consensus that DHCPv6
could/should be initiated always. I certainly don't agree with that
and don't remember a consensus call about this. If this happened in
DHC I would argue that the result is invalid because obviously those
participating there are likely to want to run DHCPv6 and under-
appreciate the notion of running DHCPv6-less.
I don't see the issue with misconfiguration if the algorithm is to do
DHCPv6 if there is just one router (or non-router, see my suggestion
about RAs with zero lifetime) sets one of the bits, even if others
don't.
We shouldn't turn a potential issue at human timescales into a
potential issue at packet transmission timescales.
Should anyone misconfigure the bits and DHCPv6 fail to work, this can
easily be fixed administratively. Should multicasts create a problem
or DHCPv6 traffic otherwise be problematic then this requires setting
up filters in the layer 2 infrastructure, which is immensely more
difficult to do.
Obviously if administrators want to configure their systems to do
DHCPv6 without the bits present in RAs then they are free to do so.
What would be bad is that this happens out of the box because there
are many non-administered or lightly administered networks where it's
not possible to change this behavior for all hosts that may show up on
the network.
In other words: if we adhere to the bits everyone can have the
situation that they want (DHCPv6/no DHCPv6) but if we don't then some
people will be confronted potentially problematic traffic that they
have to good way to get rid of.
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.
Well if you need to set up two devices then setting up a third (a
router) doesn't seem like a huge inconvience, so I don't think we
should make decisions based on this scenario.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
