Iljitsch van Beijnum <[EMAIL PROTECTED]> writes: > 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. Sure. > 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. OK, so I take it your issue boils down to "less multicast is better", as a general rule. > > 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. Can you provide some analysis/data to better define what you mean by "large amounts of airtime"? Some real numbers would help me put things in perspective. And are you talking about Wi-Fi? or some newer, more exotic WAN technology? > 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. Well, this depends on clients adhering to the "MUST NOT" invoke DHC if the bits are 0. One issue with that is we've heard (in the past) from client implementors who say they will not adhere to this, because they cannot have the reliability of their product dependent on the correct setting of the M&O bits. (I'm not saying I agree with this view, just repeating a concern that has been raised in the past.) Also, I assume your perspective is from a properly managed (i.e, enterprise) network where the operators are clueful and have full control of over the network. In the past, some folks have expressed the concern that in a home/SOHO (or less managed) environment, we may have problems with router products that always leave the bits 0, with no useful way (to laypeople that is) to configure the setting properly. > > 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. Please do not put words in my mouth or the mouths of others, it just adds noise to the discussion. Who has claimed this is a consensus view? (I certainly have not.) > 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. Nothing like raising a strawman just to shoot it down... > 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. Not necessarily in a home environment where the operator (grandma) has little technical clue and/or the $9.99 router doesn't allow one to properly/easily configure the bits. > 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. So I take you vote for MUST adherence to the M&O bits. MUST invoke if set, MUST NOT invoke of 0. > >> 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. Huh? In this ad hoc environment, there is no router available. There is no magical "third device" lying around available to configure. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
