Hi David, On Jan 4, 2006, at 16:52, David Malone wrote:
On Wed, Jan 04, 2006 at 04:08:01PM -0500, Brian Haberman wrote:I have integrated most of the changes I proposed to the ICMP Namesdraft. After my previous note on the subject, I had a lot of input onthe tunnel endpoint text and determined that there was not consensus to addit to the document.Some text seems to have been added to the draft that I don't remember being discussed here. The diff is:node MAY be configured to discard NI Queries tomulticast addresses other than its NI Group Address(es) but if so, - the default configuration MUST be not to discard them. + the default configuration SHOULD be not to discard them. An+ exception is made in the previous rule in the case of the All-Routers+ (FF02::2) and All-Nodes (FF02::1) multicast addresses. The default + configuration for responding to NI Queries to these multicast + addresses MUST be to discard them. All-nodes is one of the most useful addresses to send a node information query to. If you are trying to find a newly configured bit of kit you've just plugged in you'll query the all nodes address and see if it responds with a recognisable name. Requiring that nodes do not respond by default makes this far less useful.
This change was made to address DoS concerns raised with having the default behavior to respond to queries to the All-Nodes address. Some people have argued that allowing nodes to respond in this case simplifies an attacker's ability to map out a victim network.
Also, using the all-nodes address would be the solution if you need
to use NI queries on a network that has a mix of machines using the
old draft and the new draft. I sort of articulated this in this
message:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05925.html
without this, I don't see an obvious way to manage such a network
without sending messages to two multicast addresses, which weakens
the argument for changing the multicast range.
The change in multicast addresses was introduced to conform to RFC 3307.
(In fact, in the last around of discussions, several people suggested ditching the hashed name lookups and just keeping the unicast and regular multicast lookups, so this seems a very strange change to make.)
The primary goal of this work is to document what has already been implemented. Making the change to the multicast address was discussed with people who have already implemented the protocol to ensure it would not be a big impact. Eliminating hashed name lookups would make this protocol a new protocol (in my opinion at least). Do others have concerns with the document as it is? Regards, Brian
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
