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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
