draft-ietf-mpls-label-encaps-07.txt		draft-ietf-mpls-label-encaps-08.txt
	Network Working Group Eric C. Rosen		Network Working Group Eric C. Rosen
	Internet Draft Yakov Rekhter		Internet Draft Yakov Rekhter
	Expiration Date: March 2000 Daniel Tappan		Expiration Date: January 2001 Daniel Tappan
	Dino Farinacci
	Guy Fedorkow		Guy Fedorkow
	Cisco Systems, Inc.		Cisco Systems, Inc.
			Dino Farinacci
	Tony Li		Tony Li
	Juniper Networks, Inc.		Procket Networks, Inc.
	Alex Conta		Alex Conta
	Lucent Technologies		TranSwitch Corporation
	September 1999		July 2000
	MPLS Label Stack Encoding		MPLS Label Stack Encoding
	draft-ietf-mpls-label-encaps-07.txt		draft-ietf-mpls-label-encaps-08.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 44		skipping to change at page 1, line 45
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	"Multi-Protocol Label Switching (MPLS)" [1,2] requires a set of		"Multi-Protocol Label Switching (MPLS)" [1] requires a set of
	procedures for augmenting network layer packets with "label stacks",		procedures for augmenting network layer packets with "label stacks",
	thereby turning them into "labeled packets". Routers which support		thereby turning them into "labeled packets". Routers which support
	MPLS are known as "Label Switching Routers", or "LSRs". In order to		MPLS are known as "Label Switching Routers", or "LSRs". In order to
	transmit a labeled packet on a particular data link, an LSR must		transmit a labeled packet on a particular data link, an LSR must
	support an encoding technique which, given a label stack and a		support an encoding technique which, given a label stack and a
	network layer packet, produces a labeled packet. This document		network layer packet, produces a labeled packet. This document
	specifies the encoding to be used by an LSR in order to transmit		specifies the encoding to be used by an LSR in order to transmit
	labeled packets on PPP data links, on LAN data links, and possibly on		labeled packets on PPP data links, on LAN data links, and possibly on
	other data links as well. On some data links, the label at the top		other data links as well. On some data links, the label at the top
	of the stack may be encoded in a different manner, but the techniques		of the stack may be encoded in a different manner, but the techniques
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	4.4 Label Switching Control Protocol Configuration Options . 19		4.4 Label Switching Control Protocol Configuration Options . 19
	5 Transporting Labeled Packets over LAN Media ............ 19		5 Transporting Labeled Packets over LAN Media ............ 19
	6 IANA Considerations .................................... 20		6 IANA Considerations .................................... 20
	7 Security Considerations ................................ 20		7 Security Considerations ................................ 20
	8 Intellectual Property .................................. 20		8 Intellectual Property .................................. 20
	9 Authors' Addresses ..................................... 21		9 Authors' Addresses ..................................... 21
	10 References ............................................. 22		10 References ............................................. 22
	1. Introduction		1. Introduction
	"Multi-Protocol Label Switching (MPLS)" [1,2] requires a set of		"Multi-Protocol Label Switching (MPLS)" [1] requires a set of
	procedures for augmenting network layer packets with "label stacks",		procedures for augmenting network layer packets with "label stacks",
	thereby turning them into "labeled packets". Routers which support		thereby turning them into "labeled packets". Routers which support
	MPLS are known as "Label Switching Routers", or "LSRs". In order to		MPLS are known as "Label Switching Routers", or "LSRs". In order to
	transmit a labeled packet on a particular data link, an LSR must		transmit a labeled packet on a particular data link, an LSR must
	support an encoding technique which, given a label stack and a		support an encoding technique which, given a label stack and a
	network layer packet, produces a labeled packet.		network layer packet, produces a labeled packet.
	This document specifies the encoding to be used by an LSR in order to		This document specifies the encoding to be used by an LSR in order to
	transmit labeled packets on PPP data links and on LAN data links.		transmit labeled packets on PPP data links and on LAN data links.
	The specified encoding may also be useful for other data links as		The specified encoding may also be useful for other data links as
	skipping to change at page 3, line 38		skipping to change at page 3, line 38
	LSRs that are implemented on certain switching devices (such as ATM		LSRs that are implemented on certain switching devices (such as ATM
	switches) may use different encoding techniques for encoding the top		switches) may use different encoding techniques for encoding the top
	one or two entries of the label stack. When the label stack has		one or two entries of the label stack. When the label stack has
	additional entries, however, the encoding technique described in this		additional entries, however, the encoding technique described in this
	document MUST be used for the additional label stack entries.		document MUST be used for the additional label stack entries.
	1.1. Specification of Requirements		1.1. Specification of Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [3].		document are to be interpreted as described in RFC 2119 [2].
	2. The Label Stack		2. The Label Stack
	2.1. Encoding the Label Stack		2.1. Encoding the Label Stack
	The label stack is represented as a sequence of "label stack		The label stack is represented as a sequence of "label stack
	entries". Each label stack entry is represented by 4 octets. This		entries". Each label stack entry is represented by 4 octets. This
	is shown in Figure 1.		is shown in Figure 1.
	0 1 2 3		0 1 2 3
	skipping to change at page 5, line 30		skipping to change at page 5, line 30
	label stack.		label stack.
	In addition to learning the next hop and the label stack		In addition to learning the next hop and the label stack
	operation, one may also learn the outgoing data link		operation, one may also learn the outgoing data link
	encapsulation, and possibly other information which is needed		encapsulation, and possibly other information which is needed
	in order to properly forward the packet.		in order to properly forward the packet.
	There are several reserved label values:		There are several reserved label values:
	i. A value of 0 represents the "IPv4 Explicit NULL Label".		i. A value of 0 represents the "IPv4 Explicit NULL Label".
	This label value is only legal when it is the sole		This label value is only legal at the bottom of the
	label stack entry. It indicates that the label stack		label stack. It indicates that the label stack must be
	must be popped, and the forwarding of the packet must		popped, and the forwarding of the packet must then be
	then be based on the IPv4 header.		based on the IPv4 header.
	ii. A value of 1 represents the "Router Alert Label". This		ii. A value of 1 represents the "Router Alert Label". This
	label value is legal anywhere in the label stack except		label value is legal anywhere in the label stack except
	at the bottom. When a received packet contains this		at the bottom. When a received packet contains this
	label value at the top of the label stack, it is		label value at the top of the label stack, it is
	delivered to a local software module for processing.		delivered to a local software module for processing.
	The actual forwarding of the packet is determined by		The actual forwarding of the packet is determined by
	the label beneath it in the stack. However, if the		the label beneath it in the stack. However, if the
	packet is forwarded further, the Router Alert Label		packet is forwarded further, the Router Alert Label
	should be pushed back onto the label stack before		should be pushed back onto the label stack before
	forwarding. The use of this label is analogous to the		forwarding. The use of this label is analogous to the
	use of the "Router Alert Option" in IP packets [6].		use of the "Router Alert Option" in IP packets [5].
	Since this label cannot occur at the bottom of the		Since this label cannot occur at the bottom of the
	stack, it is not associated with a particular network		stack, it is not associated with a particular network
	layer protocol.		layer protocol.
	iii. A value of 2 represents the "IPv6 Explicit NULL Label".		iii. A value of 2 represents the "IPv6 Explicit NULL Label".
	This label value is only legal when it is the sole		This label value is only legal at the bottom of the
	label stack entry. It indicates that the label stack		label stack. It indicates that the label stack must be
	must be popped, and the forwarding of the packet must		popped, and the forwarding of the packet must then be
	then be based on the IPv6 header.		based on the IPv6 header.
	iv. A value of 3 represents the "Implicit NULL Label".		iv. A value of 3 represents the "Implicit NULL Label".
	This is a label that an LSR may assign and distribute,		This is a label that an LSR may assign and distribute,
	but which never actually appears in the encapsulation.		but which never actually appears in the encapsulation.
	When an LSR would otherwise replace the label at the		When an LSR would otherwise replace the label at the
	top of the stack with a new label, but the new label is		top of the stack with a new label, but the new label is
	"Implicit NULL", the LSR will pop the stack instead of		"Implicit NULL", the LSR will pop the stack instead of
	doing the replacement. Although this value may never		doing the replacement. Although this value may never
	appear in the encapsulation, it needs to be specified		appear in the encapsulation, it needs to be specified
	in the Label Distribution Protocol, so a value is		in the Label Distribution Protocol, so a value is
	skipping to change at page 10, line 28		skipping to change at page 10, line 28
	of the IP header checksum.		of the IP header checksum.
	It is recognized that there may be situations where a network		It is recognized that there may be situations where a network
	administration prefers to decrement the IPv4 TTL by one as it		administration prefers to decrement the IPv4 TTL by one as it
	traverses an MPLS domain, instead of decrementing the IPv4 TTL by the		traverses an MPLS domain, instead of decrementing the IPv4 TTL by the
	number of LSP hops within the domain.		number of LSP hops within the domain.
	2.4.4. Translating Between Different Encapsulations		2.4.4. Translating Between Different Encapsulations
	Sometimes an LSR may receive a labeled packet over, e.g., a label		Sometimes an LSR may receive a labeled packet over, e.g., a label
	switching controlled ATM (LC-ATM) interface [10], and may need to		switching controlled ATM (LC-ATM) interface [9], and may need to send
	send it out over a PPP or LAN link. Then the incoming packet will		it out over a PPP or LAN link. Then the incoming packet will not be
	not be received using the encapsulation specified in this document,		received using the encapsulation specified in this document, but the
	but the outgoing packet will be sent using the encapsulation		outgoing packet will be sent using the encapsulation specified in
	specified in this document.		this document.
	In this case, the value of the "incoming TTL" is determined by the		In this case, the value of the "incoming TTL" is determined by the
	procedures used for carrying labeled packets on, e.g., LC-ATM		procedures used for carrying labeled packets on, e.g., LC-ATM
	interfaces. TTL processing then proceeds as described above.		interfaces. TTL processing then proceeds as described above.
	Sometimes an LSR may receive a labeled packet over a PPP or a LAN		Sometimes an LSR may receive a labeled packet over a PPP or a LAN
	link, and may need to send it out, say, an LC-ATM interface. Then		link, and may need to send it out, say, an LC-ATM interface. Then
	the incoming packet will be received using the encapsulation		the incoming packet will be received using the encapsulation
	specified in this document, but the outgoing packet will not be sent		specified in this document, but the outgoing packet will not be sent
	using the encapsulation specified in this document. In this case,		using the encapsulation specified in this document. In this case,
	skipping to change at page 11, line 23		skipping to change at page 11, line 23
	which was originally small enough to be transmitted on that link		which was originally small enough to be transmitted on that link
	becomes too large by virtue of having one or more additional labels		becomes too large by virtue of having one or more additional labels
	pushed onto its label stack. In label switching, a packet may grow		pushed onto its label stack. In label switching, a packet may grow
	in size if additional labels get pushed on. Thus if one receives a		in size if additional labels get pushed on. Thus if one receives a
	labeled packet with a 1500-byte frame payload, and pushes on an		labeled packet with a 1500-byte frame payload, and pushes on an
	additional label, one needs to forward it as frame with a 1504-byte		additional label, one needs to forward it as frame with a 1504-byte
	payload.		payload.
	This section specifies the rules for processing labeled packets which		This section specifies the rules for processing labeled packets which
	are "too large". In particular, it provides rules which ensure that		are "too large". In particular, it provides rules which ensure that
	hosts implementing Path MTU Discovery [5], and hosts using IPv6		hosts implementing Path MTU Discovery [4], and hosts using IPv6
	[8,9], will be able to generate IP datagrams that do not need		[7,8], will be able to generate IP datagrams that do not need
	fragmentation, even if those datagrams get labeled as they traverse		fragmentation, even if those datagrams get labeled as they traverse
	the network.		the network.
	In general, IPv4 hosts which do not implement Path MTU Discovery [5]		In general, IPv4 hosts which do not implement Path MTU Discovery [4]
	send IP datagrams which contain no more than 576 bytes. Since the		send IP datagrams which contain no more than 576 bytes. Since the
	MTUs in use on most data links today are 1500 bytes or more, the		MTUs in use on most data links today are 1500 bytes or more, the
	probability that such datagrams will need to get fragmented, even if		probability that such datagrams will need to get fragmented, even if
	they get labeled, is very small.		they get labeled, is very small.
	Some hosts that do not implement Path MTU Discovery [5] will generate		Some hosts that do not implement Path MTU Discovery [4] will generate
	IP datagrams containing 1500 bytes, as long as the IP Source and		IP datagrams containing 1500 bytes, as long as the IP Source and
	Destination addresses are on the same subnet. These datagrams will		Destination addresses are on the same subnet. These datagrams will
	not pass through routers, and hence will not get fragmented.		not pass through routers, and hence will not get fragmented.
	Unfortunately, some hosts will generate IP datagrams containing 1500		Unfortunately, some hosts will generate IP datagrams containing 1500
	bytes, as long the IP Source and Destination addresses have the same		bytes, as long the IP Source and Destination addresses have the same
	classful network number. This is the one case in which there is any		classful network number. This is the one case in which there is any
	risk of fragmentation when such datagrams get labeled. (Even so,		risk of fragmentation when such datagrams get labeled. (Even so,
	fragmentation is not likely unless the packet must traverse an		fragmentation is not likely unless the packet must traverse an
	ethernet of some sort between the time it first gets labeled and the		ethernet of some sort between the time it first gets labeled and the
	skipping to change at page 15, line 22		skipping to change at page 15, line 22
	c. Forward the fragments		c. Forward the fragments
	4. If the IP datagram has the "Don't Fragment" bit set in its IP		4. If the IP datagram has the "Don't Fragment" bit set in its IP
	header:		header:
	a. the datagram MUST NOT be forwarded		a. the datagram MUST NOT be forwarded
	b. Create an ICMP Destination Unreachable Message:		b. Create an ICMP Destination Unreachable Message:
	i. set its Code field [4] to "Fragmentation Required		i. set its Code field [3] to "Fragmentation Required
	and DF Set",		and DF Set",
	ii. set its Next-Hop MTU field [5] to the difference		ii. set its Next-Hop MTU field [4] to the difference
	between the Effective Maximum Frame Payload Size		between the Effective Maximum Frame Payload Size
	and the value of N		and the value of N
	c. If possible, transmit the ICMP Destination Unreachable		c. If possible, transmit the ICMP Destination Unreachable
	Message to the source of the of the discarded datagram.		Message to the source of the of the discarded datagram.
	3.5. Processing Labeled IPv6 Datagrams which are Too Big		3.5. Processing Labeled IPv6 Datagrams which are Too Big
	To process a labeled IPv6 datagram which is too big, an LSR MUST		To process a labeled IPv6 datagram which is too big, an LSR MUST
	execute the following algorithm:		execute the following algorithm:
	skipping to change at page 16, line 29		skipping to change at page 16, line 29
	c. Forward the fragments.		c. Forward the fragments.
	Reassembly of the fragments will be done at the destination		Reassembly of the fragments will be done at the destination
	host.		host.
	3.6. Implications with respect to Path MTU Discovery		3.6. Implications with respect to Path MTU Discovery
	The procedures described above for handling datagrams which have the		The procedures described above for handling datagrams which have the
	DF bit set, but which are "too large", have an impact on the Path MTU		DF bit set, but which are "too large", have an impact on the Path MTU
	Discovery procedures of RFC 1191 [5]. Hosts which implement these		Discovery procedures of RFC 1191 [4]. Hosts which implement these
	procedures will discover an MTU which is small enough to allow n		procedures will discover an MTU which is small enough to allow n
	labels to be pushed on the datagrams, without need for fragmentation,		labels to be pushed on the datagrams, without need for fragmentation,
	where n is the number of labels that actually get pushed on along the		where n is the number of labels that actually get pushed on along the
	path currently in use.		path currently in use.
	In other words, datagrams from hosts that use Path MTU Discovery will		In other words, datagrams from hosts that use Path MTU Discovery will
	never need to be fragmented due to the need to put on a label header,		never need to be fragmented due to the need to put on a label header,
	or to add new labels to an existing label header. (Also, datagrams		or to add new labels to an existing label header. (Also, datagrams
	from hosts that use Path MTU Discovery generally have the DF bit set,		from hosts that use Path MTU Discovery generally have the DF bit set,
	and so will never get fragmented anyway.)		and so will never get fragmented anyway.)
	skipping to change at page 17, line 19		skipping to change at page 17, line 19
	- Any time the transmitting endpoint of the tunnel needs to send a		- Any time the transmitting endpoint of the tunnel needs to send a
	packet into the tunnel, and that packet has the DF bit set, and		packet into the tunnel, and that packet has the DF bit set, and
	it exceeds the tunnel MTU, the transmitting endpoint of the		it exceeds the tunnel MTU, the transmitting endpoint of the
	tunnel MUST send the ICMP Destination Unreachable message to the		tunnel MUST send the ICMP Destination Unreachable message to the
	source, with code "Fragmentation Required and DF Set", and the		source, with code "Fragmentation Required and DF Set", and the
	Next-Hop MTU Field set as described above.		Next-Hop MTU Field set as described above.
	4. Transporting Labeled Packets over PPP		4. Transporting Labeled Packets over PPP
	The Point-to-Point Protocol (PPP) [7] provides a standard method for		The Point-to-Point Protocol (PPP) [6] provides a standard method for
	transporting multi-protocol datagrams over point-to-point links. PPP		transporting multi-protocol datagrams over point-to-point links. PPP
	defines an extensible Link Control Protocol, and proposes a family of		defines an extensible Link Control Protocol, and proposes a family of
	Network Control Protocols for establishing and configuring different		Network Control Protocols for establishing and configuring different
	network-layer protocols.		network-layer protocols.
	This section defines the Network Control Protocol for establishing		This section defines the Network Control Protocol for establishing
	and configuring label Switching over PPP.		and configuring label Switching over PPP.
	4.1. Introduction		4.1. Introduction
	skipping to change at page 18, line 16		skipping to change at page 18, line 16
	4.2. A PPP Network Control Protocol for MPLS		4.2. A PPP Network Control Protocol for MPLS
	The MPLS Control Protocol (MPLSCP) is responsible for enabling and		The MPLS Control Protocol (MPLSCP) is responsible for enabling and
	disabling the use of label switching on a PPP link. It uses the same		disabling the use of label switching on a PPP link. It uses the same
	packet exchange mechanism as the Link Control Protocol (LCP). MPLSCP		packet exchange mechanism as the Link Control Protocol (LCP). MPLSCP
	packets may not be exchanged until PPP has reached the Network-Layer		packets may not be exchanged until PPP has reached the Network-Layer
	Protocol phase. MPLSCP packets received before this phase is reached		Protocol phase. MPLSCP packets received before this phase is reached
	should be silently discarded.		should be silently discarded.
	The MPLS Control Protocol is exactly the same as the Link Control		The MPLS Control Protocol is exactly the same as the Link Control
	Protocol [7] with the following exceptions:		Protocol [6] with the following exceptions:
	1. Frame Modifications		1. Frame Modifications
	The packet may utilize any modifications to the basic frame		The packet may utilize any modifications to the basic frame
	format which have been negotiated during the Link Establishment		format which have been negotiated during the Link Establishment
	phase.		phase.
	2. Data Link Layer Protocol Field		2. Data Link Layer Protocol Field
	Exactly one MPLSCP packet is encapsulated in the PPP		Exactly one MPLSCP packet is encapsulated in the PPP
	skipping to change at page 21, line 19		skipping to change at page 21, line 19
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA, 01824		Chelmsford, MA, 01824
	E-mail: erosen@cisco.com		E-mail: erosen@cisco.com
	Dan Tappan		Dan Tappan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA, 01824		Chelmsford, MA, 01824
	E-mail: tappan@cisco.com		E-mail: tappan@cisco.com
	Dino Farinacci
	Cisco Systems, Inc.
	170 Tasman Drive
	San Jose, CA, 95134
	E-mail: dino@cisco.com
	Yakov Rekhter		Yakov Rekhter
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA, 95134		San Jose, CA, 95134
	E-mail: yakov@cisco.com		E-mail: yakov@cisco.com
	Guy Fedorkow		Guy Fedorkow
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA, 01824		Chelmsford, MA, 01824
	E-mail: fedorkow@cisco.com		E-mail: fedorkow@cisco.com
			Dino Farinacci
			Procket Networks, Inc.
			3910 Freedom Circle, Ste. 102A
			Santa Clara, CA 95054
			E-mail: dino@procket.com
	Tony Li		Tony Li
	Juniper Networks		Procket Networks, Inc.
	385 Ravendale Dr.		3910 Freedom Circle, Ste. 102A
	Mountain View, CA, 94043		Santa Clara, CA 95054
	E-mail: tli@juniper.net		E-mail: tli@procket.com
	Alex Conta		Alex Conta
	Lucent Technologies		TranSwitch Corporation
	300 Baker Avenue		3 Enterprise Drive
	Concord, MA, 01742		Shelton, CT, 06484
	E-mail: aconta@lucent.com		E-mail: aconta@txc.com
	10. References		10. References
	[1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label		[1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label
	Switching Architecture", Work in Progress, April 1999.		Switching Architecture", Work in Progress, July 2000.
	[2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G.,
	Viswanathan, A., "A Framework for Multiprotocol Label Switching",
	Work in Progress, November 1997.
	[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, BCP 14, March 1997.		Levels", RFC 2119, BCP 14, March 1997.
	[4] Postel, J., "Internet Control Message Protocol", RFC 792,		[3] Postel, J., "Internet Control Message Protocol", RFC 792,
	September 1981.		September 1981.
	[5] Mogul, J. and Deering S., "Path MTU Discovery", RFC 1191,		[4] Mogul, J. and Deering S., "Path MTU Discovery", RFC 1191,
	November 1990.		November 1990.
	[6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.		[5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
	[7] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC		[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
	1661, STD 51, July 1994.		1661, STD 51, July 1994.
	[8] Conta, A. and Deering, S., "Internet Control Message Protocol		[7] Conta, A. and Deering, S., "Internet Control Message Protocol
	(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification",		(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification",
	RFC 1885, December 1995.		RFC 1885, December 1995.
	[9] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery for IP		[8] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery for IP
	version 6", RFC 1981, August 1996.		version 6", RFC 1981, August 1996.
	[10] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E.		[9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E.
	and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in		and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in
	Progress, April 1999.		Progress, June 2000.
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/