Browse Prior Art Database

Inverse Address Resolution Protocol (RFC2390)

IP.com Disclosure Number: IPCOM000002963D
Original Publication Date: 1998-Sep-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 8 page(s) / 19K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

T. Bradley: AUTHOR [+3]

Abstract

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. Specifically, this applies to Frame Relay stations that may have a Data Link Connection Identifier (DLCI), the Frame Relay equivalent of a hardware address, associated with an established Permanent Virtual Circuit (PVC), but do not know the protocol address of the station on the other side of this connection. It will also apply to other networks with similar circumstances.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 14% of the total text.

Network Working Group T. Bradley

Request for Comments: 2390 Avici Systems, Inc.

Obsoletes: 1293 C. Brown

Category: Standards Track Consultant

A. Malis

Ascend Communications, Inc.

September 1998

Inverse Address Resolution Protocol

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 (1998). All Rights Reserved.

2. Abstract

This memo describes additions to ARP that will allow a station to

request a protocol address corresponding to a given hardware address.

Specifically, this applies to Frame Relay stations that may have a

Data Link Connection Identifier (DLCI), the Frame Relay equivalent of

a hardware address, associated with an established Permanent Virtual

Circuit (PVC), but do not know the protocol address of the station on

the other side of this connection. It will also apply to other

networks with similar circumstances.

This memo replaces RFC 1293. The changes from RFC 1293 are minor

changes to formalize the language, the additions of a packet diagram

and an example in section 7.2, and a new security section.

3. Conventions

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,

SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this

document, are to be interpreted as described in [5].

4. Introduction

This document will rely heavily on Frame Relay as an example of how

the Inverse Address Resolution Protocol (InARP) can be useful. It is

not, however, intended that InARP be used exclusively with Frame

Relay. InARP may be used in any network that provides destination

hardware addresses without indicating corresponding protocol

addresses.

5. Motivation

The motivation for the development of Inverse ARP is a result of the

desire to make dynamic address resolution within Frame Relay both

possible and efficient. Permanent virtual circuits (PVCs) and

eventually switched virtual circuits (SVCs) are identified by a Data

Link Connection Identifier (DLCI). ...