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 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.