I would be happy with configuration feature that would allow: 1) Use old (depricated) multicast address 2) Use Solicited Node range multicast address 3) Disable name hashed multicast addresses completly The RFC would depricate the old multicast address.
Given these changes then I could recommend using the implementation if it was updated to conform to the RFC. I think the usefulness of Name lookups is very small. IMHO, most name queries will be done via DNS. The advantage of this feature to me is obtaining other addresses by quering the link local address or via the All-Hosts multicast address. (But I am looking at this from a network management/security view) I am not sure of any OS when performing name resolutions use the name hashing lookup method and that would only work on a local link. The only querier that I am aware of is Ping6 on NetBSD and OSX. Are there any OS that implement the responder side in the OS itself? I have native NetBSD and it does not respond to these requests. -----Original Message----- From: Elwyn Davies [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 21, 2005 13:15 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: Brian Haberman; IPv6 WG Subject: Re: IPv6 WG Last Call: <draft-ietf-ipngwg-icmp-name-lookups-12.txt> In the light of the previous discussion I had with Ron on this subject, it occurs to me that it would address Ron's issue if responders joined both the old 32 bit and the Solicited Node related multicast addresses. Queriers that are worried about real time issues can use the new Solicited Node related address and the 32 bit address could be deprecated. Configuration could allow the old address to be switched off if a network has multicast resource issues in routers. Regards, Elwyn Pashby, Ronald W CTR NSWCDD-B35 wrote: >Brian, > >I agree with the suggestion. My understanding is that this is used for on-link >queries (especially the name lookup) which is a link local multicast. > >We also need to get comments on the proposal of limiting the multicast id to >0xFF000000 - 0xFFFFFFFF (overlaying the Solicited Node range). Here is my >comments on the multicast range. > >I would like to support this draft, because it provides enhanced network >management capabilities. However with the current multicast address selection, >I cannot recommend that any equipment with this implemented to be connected to >any mission critical networks (e.g. nuclear reactor control, combat systems, >navigation control, real-time financial) that utilize multicast. > >The problem with MD5 hashing the name and using the 32 bits directly for the >lower 32 bits of the multicast address is that, an unsuspecting host can be >flooded with multicast traffic, just because it joined the multicast group for >name lookup queries. This could cause the host to fail in performing its >real-time mission critical task. A small probability of this occurring is not >acceptable, if making it zero is easily accomplished by limiting the range. > >The solution is to map the hashed name into a range of multicast ids that will >not collide with other "real" multicast streams. I recommend that 24 bits of >the hash are used and a 0xFF be appended, mapping it into the Solicited Node >range. I have another draft, draft-pashby-mboned-mc-scoped-addr-00 that >further defines the ranges that are specified by RFC3307. These further >breakdowns, will isolate other multicast traffic colliding with the Solicited >Node range. This draft was scheduled to be discussed in the mboned wg, but was >not discussed when mboned wg and imad bof were combined. > >I understand this breaks implementations, but I would rather break >implementations that are written to a draft, rather than allow implementations >that could cause catastrophic problems in real-time mission critical networks. > >Ron > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of >Brian Haberman >Sent: Tuesday, September 20, 2005 13:13 >To: IPv6 WG >Subject: Re: IPv6 WG Last Call: ><draft-ietf-ipngwg-icmp-name-lookups-12.txt> > > > >On Aug 1, 2005, at 2:08, Pekka Savola wrote: > > > >>On Fri, 15 Jul 2005, Bob Hinden wrote: >> >> >>>This starts a two week IPv6 working group last call on advancing: >>> >>> Title : IPv6 Node Information Queries >>> Author(s) : M. Crawford, B. Haberman >>> Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt >>> Pages : 14 >>> Date : 2005-7-14 >>> >>>to Experimental. Please send substantive comments to the IPv6 >>>mailing list. Editorial comments can be sent to the authors. >>> >>> >>Sorry for missing the DL by a couple of days, but here are my comments >>anyway. >> >>I've been very critical of the node information queries in the past, >>and >>still am, but as it's going to Experimental, I'm not as concerned. >>However, >>I think there are still a couple of very important things which need >>to be >>settled so that a) it can be used safely and b) it won't jeopardize >>the real >>use of IPv6 ICMP messages. >> >>Specifically, I'm very concerned about its use with global addresses, >>over >>the Internet. This has a potential to turn into a kitchen sink >>protocol, >>which can be used to do query anything at all from a random node. >>This is >>exactly the thing that makes want to firewall administrators filter out >>all ICMPv6 messages just to be sure messages like this won't be used >>in the systems. I don't think we want that. >> >>I have no objection to having a protocol like this used between >>consenting >>adults between link-local addresses or even global addresses if done >>over a >>single link -- but extending it (or providing extendibility) beyond >>that >>seems unwise. >> >>My suggestion how to deal with this is to: >> - add that a node MUST send all non-link-local node information >>queries >> with Hop Count 255; HC=255 MAY [or SHOULD] be used with other >>traffic >> as well; and >> - a node MUST, unless explicitly configured otherwise, discard any >>node >> information queries w/ non-link-local queries which don't have >>HC=255. >> >>This only breaks backward compat for node information queries sent w/ >>global >>addresses, over one hop away. I think we could live with that. It >>should >>provide a sufficiently simple security model for ensuring NIQ's won't >>be >>used inappropriately. >> >> >> > >I would like to solicit opinions from the working group on the >suggestions >above. Specifically, the proposal would render existing implementations >non-conformant to the spec. The primary goal of this work has been to >document what the existing code bases support, so I will not make this >change unless I see a true consensus to do so. > >Please provide comments by Sept. 28, 2005. > >Regards, >Brian > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
