On Aug 22, 2003, at 10:03 PM, Bound, Jim wrote:
mdns or LLMNR are not widely implemented and if you bring your
implementation to one of the many test events for IPv6 where your node
must interoperate on the deployed implementations testing network most
nodes will not respond to mdns. I am sure you can interoperate with
your own nodes. But think about a network where your nodes are only say
10 out of 30 on two links. Your mdns will not work with the other nodes
for IPv6LLs.
We are trying to push for a wider adoption of mDNS. We were trying to work with the IETF to establish it as a standard, but the working group ran it in to the ground as LLMNR to such a state that we can not use it. We continue working on mDNS since LLMNR is in such a useless state. Our implementation of mDNS can be built on many platforms. We feel that mDNS combined with IPv6LL addresses make for a very powerful solution to the problems of local communication on both configured and unconfigured networks.
My postulate is that major pain can be caused by sending to the wrong IPv6LL in a multilink scenario if the packet goes to the wrong link. How does the user know to specify applicationname FE80::1%ethernet0, ethernnet1, etc.?
On our implementation, if the scope is not specified the transmit fails. I think it results in a no route to host error. This means that the scope id must be specified for a link-local address. In the case of mDNS, this is automatic. In the case of manually typing an address, the user must append the scope id to the IPv6LL address (i.e. fe80::123%en0). Some browsers choke on this, treating the % as an escape character. Most browsers handle this correctly when the IPv6 address is correctly bracketed by '[' and ']'.
Because of this potential conflict today it needs to be documented publicly.
That does not mean in worst case scenarios of no router and no assigned
prefix for ad hoc network IPv6LLs cannot be used but rather some serious
thought should go into their use by what I call mission critical
applications.
Suggesting that applications should avoid IPv6LLs at all cost is silly. IPv6LLs will work transparently with the vast majority of existing applications. Applications that have special requirements (those transmitting an address in a packet) will need to filter out such addresses for any destination that may potentially be off link. Those applications may also need to remember the interface packets were received on in the case of an IPv6LL being forwarded to another node on the same link, just as our mDNSResponder and resolver libraries do. This is not a difficult concept to grasp nor is the code very complicated. I'm surprised it has sparked such a heated debate.
-josh
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
