Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
RFC 3122

Document Type RFC - Proposed Standard (June 2001; Errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3122 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           A. Conta
Request for Comments: 3122                        Transwitch Corporation
Category: Standards Track                                      June 2001

      Extensions to IPv6 Neighbor Discovery for Inverse Discovery
                             Specification

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This memo describes extensions to the IPv6 Neighbor Discovery that
   allow a node to determine and advertise an IPv6 address corresponding
   to a given link-layer address.  These extensions are called Inverse
   Neighbor Discovery.  The Inverse Neighbor Discovery (IND) was
   originally developed for Frame Relay networks, but may also apply to
   other networks with similar behavior.

Conta                       Standards Track                     [Page 1]
RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001

Table of Contents

   1. Introduction.................................................... 3
   2. Inverse Neighbor Discovery Messages............................. 3
      2.1 Inverse Neighbor Discovery Solicitation Message............. 3
      2.2 Inverse Neighbor Discovery Advertisement Message............ 5
   3. Inverse Neighbor Discovery Options Format....................... 6
      3.1 Target Address List......................................... 6
   4. Inverse Neighbor Discovery Protocol............................. 9
      4.1 Sender Node Processing...................................... 9
      4.2 Receiver Node Processing.................................... 9
        4.2.1 Processing Inverse Neighbor Discovery Solicitations..... 9
        4.2.2 Processing Inverse Neighbor Discovery Advertisements... 10
      4.3 Message Validation......................................... 10
        4.3.1 Validation of Inverse Neighbor Discovery Solicitations. 10
        4.3.2 Validation of Inverse Neighbor Discovery Advertisements 11
   5. Security Considerations........................................ 12
   6. IANA Considerations............................................ 13
   7. Acknowledgments................................................ 13
   8. References..................................................... 13
   9. Authors' Addresses............................................. 14
   Appendix A........................................................ 15
   Full Copyright Statement.......................................... 20

Conta                       Standards Track                     [Page 2]
RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001

1. Introduction

   This document defines extensions to the IPv6 Neighbor Discovery
   (ND)[IPv6-IND].  The extensions are called IPv6 Inverse Neighbor
   Discovery (IND).  The IPv6 Inverse Neighbor Discovery (IND) allows a
   node that knows the link-layer address of a directly connected remote
   node to learn the IPv6 addresses of that node.  A node using IND
   sends solicitations and receives advertisements for one or more IPv6
   addresses corresponding to a known link-layer address.

   The Inverse Neighbor Discovery (IND) was originally developed for
   Frame Relay networks, but may also apply to other networks with
   similar behavior.

   The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
   SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
   in [KEYWORDS].

   There are a number of similarities and differences between the
   mechanisms described here and those defined for Inverse ARP for IPv4
   in [INV-ARP] or its replacement documents.

2. Inverse Neighbor Discovery Messages

   The following messages are defined:

2.1. Inverse Neighbor Discovery Solicitation Message

   A node sends an Inverse Neighbor Discovery Solicitation message to
   request an IPv6 address corresponding to a link-layer address of the
   target node while also providing its own link-layer address to the
   target.  Since the remote node IPv6 addresses are not known, Inverse
   Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node
   multicasts [IPv6], [IPv6-FR], [ENCAPS].  However, at link layer
   level, an IND Solicitation is sent directly to the target node,
   identified by the known link-layer address.
Show full document text