Internet DRAFT - draft-pashby-ipv6-network-discovery
draft-pashby-ipv6-network-discovery
Network Working Group R. Pashby
Internet Draft Bowhead Support
Document: draft-pashby-ipv6-network-discovery-00.txt July 2005
Expires: January 2006
Changes Needed to Allow for IPv6 Network Discovery
<draft-pashby-ipv6-network-discovery-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2006.
Abstract
The purpose of the draft is to provide mechanisms to discover all
nodes and addresses on an IPv6 network.
Network discovery is a key to network management and network
security. In IPv4 the most effective way to discover what devices
were attached to the network was to walk the entire network address
space. While this was easily done in IPv4, it is impossible in
IPv6, due to the large range of addresses on a network. Currently
there is no effective way to discover the nodes on an IPv6 network.
This document describes the changes that need to be made to allow
for discovering nodes on an IPv6 network.
Table of Contents:
1. Introduction
2. Applicability
3. Changes to ICMP Echo Request [RFC2463] processing
4. Recommendations for Inverse Neighbor Discovery
5. Recommendations for ICMP Names protocol
6. Security Considerations
7. Acknowledgments
8. References
9. Author's Information
1. Introduction
The purpose of the draft is to provide mechanisms to discover all
nodes and addresses on an IPv6 network.
Network discovery is a key to network management and network
security. In IPv4 the most effective way to discover what devices
were attached to the network was to walk the entire network address
space. While this was easily done in IPv4, it is impossible in
IPv6, due to the large range of addresses on a network. Currently
there is no effective way to discover the nodes on an IPv6 network.
Currently, there exists a method to send an ICMP [RFC2463] Echo
Request to the All Hosts Multicast address and all IPv6 nodes will
respond. Unfortunately they respond with their Link Local Address
and all the responses are sent in a very short period of time.
There currently is defined an Inverse Neighbor Discovery (IND)
protocol [RFC3122] that could be used to retrieve the global
addresses of the node. However, this method is not mandatory to be
implemented and there are few if any implementations.
There is also the new ICMP Names protocol [icmpnames] being defined
that could be used to obtain, not only the global addresses of the
interface being queried but also all global addresses and the host
name. The draft that defined this method, draft-ietf-icmp-names-
06.txt has expired and currently being resubmitted.
This document recommends:
1) Minor changes to the existing ICMP specifications.
2) That the IND become mandatory for all interfaces, with minor
changes.
3) The acceptance of the ICMP Names protocol, with minor changes
and recommends that all IPv6 nodes to implement it.
2. Applicability
These changes are necessary for discovery of IPv6 nodes on
networks. In order that every network is capable of being managed
these changes shall be implemented in all IPv6 nodes.
3. Changes to ICMP Echo Request [RFC2463] processing
If the Echo Request is received via a Multicast address then a
hold-off timer shall be used to delay the sending of the Echo
Response until the hold-off timer expires.
During the hold-off period all other Multicast Echo Requests shall
be silently discarded. Discarded Echo Requests may be logged for
security reasons. The hold-off time shall be an evenly distributed
random time between 0 and MaxHoldOff, with a resolution of at least
10mS. The default MaxHoldOff value shall be 30 seconds.
4. Recommendations for Inverse Neighbor Discovery
The Inverse Neighbor Discovery protocol [RFC3122] shall be
implemented in all IPv6 nodes, for all interfaces. Additionally,
the hold-off timer described above shall be implemented for all
Multicast IND Requests.
5. Recommendations for ICMP Names protocol
The ICMP Names protocol [icmpnames] shall be accepted and should be
implemented in all IPv6 nodes. Additionally, the hold-off timer
described above shall be implemented for all Multicast ICMP Name
requests.
6. Security Considerations
These recommendations do not inherently introduce any new security
issues. The ability of devices to discover information about other
devices on the network does raise security concerns. There is a
tradeoff between absolute security and network manageability. Good
network security mandates good network management for detecting
unauthorized devices on the network. The procedures for discovering
IPv6 nodes described here utilize link-level multicast mechanisms
that are confined to the local link only and cannot be used from
beyond the network. The hold-off procedure described in this
document will reduce the effect of Denial of Service attacks,
involving multicast requests.
7. Acknowledgments
Brian Haberman, John Hopkins University
Karen O'Donoghue, US Department of Navy
8. References
[RFC2463] Conta, A., Deering, S.," Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6)", RFC2463, December 1998
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery Specification", RFC3122, June 2001
[icmpnames] Crawford, M., Haberman, B., "IPv6 Node Information
Queries", draft-ietf-ipv6-icmp-name-lookups-11, May
2005
9. Author's Information
Ronald Pashby
Bowhead Support Services
Ronald.Pashby.ctr@navy.mil
(540) 653-6070
Copyright (C) The Internet Society (2005)
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors retain
all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.