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.