< draft-ietf-ion-inarp-update-01.txt		draft-ietf-ion-inarp-update-02.txt >
	Network Working Group T. Bradley		Network Working Group T. Bradley
	INTERNET-DRAFT Avici Systems, Inc.		INTERNET-DRAFT Avici Systems, Inc.
	Obsoletes: 1293 C. Brown		Obsoletes: 1293 C. Brown
	<draft-ietf-ion-inarp-update-01.txt> Fore Systems, Inc.		<draft-ietf-ion-inarp-update-02.txt> Fore Systems, Inc.
	A. Malis		A. Malis
	Cascade Communications Corp.		Ascend Communications, Inc.
	May 7, 1997		March 11, 1998
	Expires November 7, 1997		Expires September 10, 1998
	Inverse Address Resolution Protocol		Inverse Address Resolution Protocol
	1. Status of this Memo		1. Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	This memo describes additions to ARP that will allow a station to		This memo describes additions to ARP that will allow a station to
	request a protocol address corresponding to a given hardware address.		request a protocol address corresponding to a given hardware address.
	Specifically, this applies to Frame Relay stations that may have a		Specifically, this applies to Frame Relay stations that may have a
	Data Link Connection Identifier (DLCI), the Frame Relay equivalent of		Data Link Connection Identifier (DLCI), the Frame Relay equivalent of
	a hardware address, associated with an established Permanent Virtual		a hardware address, associated with an established Permanent Virtual
	Circuit (PVC), but do not know the protocol address of the station on		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		the other side of this connection. It will also apply to other
	networks with similar circumstances.		networks with similar circumstances.
	3. Conventions		This memo replaces RFC 1293. The changes from RFC 1293 are minor
	The following language conventions are used in the items of		changes to formalize the language, and the additions of a packet
	specification in this document:		diagram in section 7.2 and a new security section.
	o Must, Will, Shall or Mandatory -- the item is an absolute
	requirement of the specification.
	o Should or Recommended -- the item should generally be		3. Conventions
	followed for all but exceptional circumstances.
	o May or Optional -- the item is truly optional and may be		The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
	followed or ignored according to the needs of the		SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
	implementor.		document, are to be interpreted as described in [5].
	4. Introduction		4. Introduction
	This document will rely heavily on Frame Relay as an example of how		This document will rely heavily on Frame Relay as an example of how
	the Inverse Address Resolution Protocol (InARP) can be useful. It is		the Inverse Address Resolution Protocol (InARP) can be useful. It is
	not, however, intended that InARP be used exclusively with Frame		not, however, intended that InARP be used exclusively with Frame
	Relay. InARP may be used in any network that provides destination		Relay. InARP may be used in any network that provides destination
	hardware addresses without indicating corresponding protocol		hardware addresses without indicating corresponding protocol
	addresses.		addresses.
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 9 ¶
	ar$spa - protocol address requested		ar$spa - protocol address requested
	ar$tha - Q.922 address of requesting station		ar$tha - Q.922 address of requesting station
	ar$tpa - protocol address of requesting station		ar$tpa - protocol address of requesting station
	Note that the Q.922 addresses specified have the C/R, FECN, BECN, and		Note that the Q.922 addresses specified have the C/R, FECN, BECN, and
	DE bits set to zero.		DE bits set to zero.
	Procedures for using InARP over a Frame Relay network are identical		Procedures for using InARP over a Frame Relay network are identical
	to those for using ARP and RARP discussed in [3].		to those for using ARP and RARP discussed in [3].
	8. References		8. Security Considerations
			This document specifies a functional enhancement to the ARP family of
			protocols, and is subject to the same security constraints that
			affect ARP and similar address resolution protocols. Because
			authentication is not a part of ARP, there are known security issues
			relating to its use (e.g., host impersonation). No additional
			security mechanisms have been added to the ARP family of protocols by
			this document.
			9. References
	[1] Plummer, D., "An Ethernet Address Resolution Protocol - or -		[1] Plummer, D., "An Ethernet Address Resolution Protocol - or -
	Converting Network Protocol Addresses to 48.bit Ethernet Address		Converting Network Protocol Addresses to 48.bit Ethernet Address
	for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT,		for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT,
	November 1982.		November 1982.
	[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,		[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
	USC/Information Sciences Institute, October 1994		USC/Information Sciences Institute, October 1994
	[3] Bradley, T., Brown, C., Malis, A., "Multiprotocol Interconnect		[3] Brown, C., Malis, A., "Multiprotocol Interconnect over Frame
	over Frame Relay", RFC 1490, July 1993.		Relay", RFC 1490, July 1993.
	[4] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse		[4] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse
	Address Resolution Protocol", STD 38, RFC 903, Stanford		Address Resolution Protocol", STD 38, RFC 903, Stanford
	University, June 1984.		University, June 1984.
	9. Security Considerations
	Security issues are not addressed in this memo.		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119, Harvard University, March 1997.
	10. Authors' Addresses		10. Authors' Addresses
	Terry Bradley		Terry Bradley
	Avici Systems, Inc.		Avici Systems, Inc.
	12 Elizabeth Drive		12 Elizabeth Drive
	Chelmsford, MA 01824		Chelmsford, MA 01824
	Phone: (508) 250-3344		Phone: (978) 250-3344
	Email: tbradley@avici.com		Email: tbradley@avici.com
	Caralyn Brown		Caralyn Brown
	FORE Systems, Inc.		FORE Systems, Inc.
	1 Corporate Drive		1 Corporate Drive
	Andover, MA 01810		Andover, MA 01810
	Phone: (508) 689-2400 x133		Phone: (978) 689-2400 x133
	Email: cbrown@fore.com		Email: cbrown@fore.com
	Andrew Malis		Andrew Malis
	Cascade Communications Corp.		Ascend Communications, Inc.
	5 Carlisle Road		1 Robbins Road
	Westford, MA 01886		Westford, MA 01886
	Phone: (508) 952-7414		Phone: (978) 952-7414
	Email: malis@casc.com		Email: malis@ascend.com
End of changes. 16 change blocks.
	32 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/