Selon Jari Arkko <[EMAIL PROTECTED]>: > Pars, > > Various possible DNS designs are possible. However, > I want to go back to your suggestion that multicasting > will cause significant inefficiencies when running over > WiMax and 802.16. >
Thank you very much for this mail. Please see below: > It might, indeed -- Christian's note about the high > speed wireless designs was right on. But the question > is whether it will actually be the case for WiMax as > it is being defined and used. As you may know, there has > been active work in the 16ng working group during the > summer and autumn, and that has resulted in a > number of changes to the way that people originally > planned to run this. In particular, the WG has > considered issues relating to waking up dormant > hosts. My understanding is that their current > designs do NOT have that problem. For instance, > they plan to recommend a point to point like link > model where the host's ND or other link local > multicast traffic does not impact other hosts. > And there is a plan on employing RFC 4541 (MLD > snooping) where 802.16 is run as an Ethernet. > As a result, it seems fairly effective in ensuring > that multicast does not wake up unnecessary > neighbors. Great news. This means that ND and DAD will work without waking up all dormant hosts. If I understand correctly. > It does not solve all problems -- if > you were to run LLMNR over it you would still > be sending to every node, because only one > multicast address is used. But then again, > I'm not sure how big practical problem this > is. I hope the providers are not setting up > their 802.16 networks so that people can > find printer.local in the Tokyo subnet... I'm not sure why LLMNR uses only one multicast address. I see serious problems with that. A LLMNR query would wake up every dormant host, in this case. Why this may be a serious problem? Firstly, the multicast name resolution idea that started with ZEROCONF (if I'm correct), has the potential to find many new and popular applications. This means that many users may use it in the future, especially in wireless broadband networks. However, this also means that it may create a lot of multicast queries that wake up every host and consume a lot of energy. >From this point of view, I suspect that LLMNR's potentials are underestimated by its own design. (I mean: if a LLMNR query must be forwarded to every node) Secondly, nothing prevents a user from trying different names again and again. Each query would wake up many dormant hosts. Can we call this a DoS attack? I'm not even sure. He/she is doing that for fun perhaps. But the consequences would be bad if a LLMNR query must be forwarded to all (probably dormant) devices. > > Anyway, if we think of the hash approach independently > of your 802.16 use case, I think there are still several > significant problems. As others have mentioned, you > still need something that allows ND to work, and it, > in turn is based on multicast at IP level. Perhaps > more fundamentally, I think a local unmanaged naming > system should be able to live with collisions. As your > scheme combines the name space to the IP space > this becomes very difficult. For starters, to allow > multiple similar names, you would have to disable > DAD and change ND, and I suspect it would not work > with current TCP and applications. Also, there > are operational issues such as inability to search > except for exact match. Pushing my own scheme is not my intent in this discussion. (I wanted feedback, and I had a lot and I thank you all) However, the good news that you have announced in your mail are also good news for my proposal. My proposal *needs* ND for address resolution, and DAD for address (i.e. name) collision detection. If these protocols will run without waking up every dormant host, then this is also great for me. I will think more about your other comments (I'm not sure to understand). Thanks! pars ps: I'm not sure if folks realize the costs of waking up every dormant host at the same time. It is not only an energy consumption problem. It is also a signaling problem. The most efficient dormant is achieved using a mechanism called "paging". This is a generic protocol. To wake up a dormant host, you have to search it in many cells. This is for one host. You can probably imagine what would happen if you try to page every dormant host. > > Jari > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
