John, Very good response. Lets go offline. I think mdns should be revisited from your mail in the IETF.
Thanks /jim > -----Original Message----- > From: Joshua Graessley [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 24, 2003 12:50 AM > To: [EMAIL PROTECTED] > Subject: Re: Some IPv6LL operational experience > > > > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
