< draft-ietf-ion-ipv6-fr-01.txt		draft-ietf-ion-ipv6-fr-02.txt >
	skipping to change at page 1, line 15 ¶		skipping to change at page 1, line 15 ¶
	A. Malis		A. Malis
	(Ascend)		(Ascend)
	M. Mueller		M. Mueller
	(Lucent)		(Lucent)
	January 1999		January 1999
	Transmission of IPv6 Packets over Frame Relay Networks		Transmission of IPv6 Packets over Frame Relay Networks
	Specification		Specification
	draft-ietf-ion-ipv6-fr-01.txt		draft-ietf-ion-ipv6-fr-02.txt
	Status of this Memo		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.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	document defines two distinct formats for the ND and IND messages		document defines two distinct formats for the ND and IND messages
	Link-Layer Address field:		Link-Layer Address field:
	(a) DLCI Format -- used in ND and/or IND messages on VCs that were		(a) DLCI Format -- used in ND and/or IND messages on VCs that were
	established prior to the ND or IND message exchange -- mostly		established prior to the ND or IND message exchange -- mostly
	PVCs. The use on SVCs makes sense with Inverse Neighbor		PVCs. The use on SVCs makes sense with Inverse Neighbor
	Discovery [IND] messages if IND is employed after the successful		Discovery [IND] messages if IND is employed after the successful
	establishing of an SVC to gather information about other IPv6		establishing of an SVC to gather information about other IPv6
	addresses assigned to the remote node and that SVC.		addresses assigned to the remote node and that SVC.
	The use of the override "O" bit [ND] SHOULD be consistent with
	the type of Link-Layer Address format: an implementation should
	override one address format in its cache with the same type of
	address format. The "O" bit SHOULD be clear in the Neighbor
	Discovery Advertisement message containing such a Link-Layer
	Address format in case the sender of the message does not wish
	the recipient to override existing information in its cache[ND].
	(b) Frame Relay Address Format -- used mostly prior to establishing		(b) Frame Relay Address Format -- used mostly prior to establishing
	a new SVC, to get the Frame Relay remote node identifier		a new SVC, to get the Frame Relay remote node identifier
	(link-layer address) mapping to a certain IPv6 address.		(link-layer address) mapping to a certain IPv6 address.
	The override "O" bit in the Neighbor Discovery Advertisement		Note: An implementation may hold both types of link layer
	message MAY be set to 1, in order to allow refreshing a cache		identifiers in the Neighbor Discovery cache. Additionally, in case
	entry which maps an IPv6 address to an E.164, X.121, or NSAP		of multiple VCs between two nodes, one node's Neighbor Discovery
	address.		cache may hold a mapping of one of the remote node's IPv6
			addresses to each and every DLCI identifying the VCs.
			The mechanisms which in such an implementation would make the
			distinction between the Neighbor Discovery Cache mapping of an
			IPv6 address to a "Frame Relay Address Format" and a "DLCI Format"
			link-layer address, or among several mappings to a "DLCI Format"
			addresses are beyond the scope of this specification.
			The use of the override "O" bit in the advertisement messages that
			contain the above Link-Layer Address formats SHOULD be consistent
			with the [ND] specifications. Additionally, there should be
			consistency related to the type of Link-Layer Address format: an
			implementation should override one address format in its Neighbor
			Discovery cache with the same type of address format.
	The "DLCI Format" is defined as follows:		The "DLCI Format" is defined as follows:
	7 6 5 4 3 2 1 0 (bit order)		7 6 5 4 3 2 1 0 (bit order)
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	0 | Type |		0 | Type |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	1 | Length |		1 | Length |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	with a DLCI (Q.922 address) encoded as option value:		with a DLCI (Q.922 address) encoded as option value:
	7 6 5 4 3 2 1 0 (bit order)		7 6 5 4 3 2 1 0 (bit order)
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	2 | | 1 | 1 |		2 | | 1 | 1 |
	+ unused +-----+-----+		+ unused +-----+-----+
	3 | |		3 | |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	4 | DLCI(high order) | 0 | 0 |		4 | DLCI(high order) | 0 | 0 |
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
End of changes. 4 change blocks.
	14 lines changed or deleted		19 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/