draft-ietf-mpls-icmp-02.txt		draft-ietf-mpls-icmp-03.txt
	MPLS Working Group R.Bonica		MPLS Working Group R.Bonica
	Internet Draft MCIWorldCom		Internet-Draft D. Gan
	Document: draft-ietf-mpls-icmp-02.txt D.Tappan		Expires: February 3, 2006 Juniper Networks
	Cisco Systems		D. Tappan
	D.Gan		Cisco Systems, Inc.
	Juniper Networks		August 2, 2005
	August 2000
	ICMP Extensions for MultiProtocol Label Switching		ICMP Extensions for MultiProtocol Label Switching
			draft-ietf-mpls-icmp-03
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, each author represents that any
	all provisions of Section 10 of [RFC-2026].		applicable patent or other IPR claims of which he or she is aware
			have been or will be disclosed, and any of which he or she becomes
			aware will be disclosed, in accordance with Section 6 of BCP 79.
	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. Internet-Drafts are draft documents valid for a maximum of		Drafts.
	six months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts as		Internet-Drafts are draft documents valid for a maximum of six months
	reference material or to cite them other than as "work in progress."		and may be updated, replaced, or obsoleted by other documents at any
			time. It is inappropriate to use Internet-Drafts as reference
			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.
	1. Abstract		This Internet-Draft will expire on February 3, 2006.
	The current memo proposes extensions to ICMP that permit Label		Copyright Notice
	Switching Routers to append MPLS information to ICMP messages.
	2. Conventions used in this document		Copyright (C) The Internet Society (2005).
			Abstract
			This memo proposes extensions to ICMP that permit Label Switching
			Routers to append MPLS information to ICMP messages.
			Table of Contents
			1. Conventions Used In This Document . . . . . . . . . . . . . . 3
			2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
			3. Application to TRACEROUTE . . . . . . . . . . . . . . . . . . 5
			4. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 6
			5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
			5.1 Common Header . . . . . . . . . . . . . . . . . . . . . . 8
			5.2 Object Header . . . . . . . . . . . . . . . . . . . . . . 8
			5.3 MPLS Stack Entry Object Class . . . . . . . . . . . . . . 9
			5.4 Extended Payload Object Class . . . . . . . . . . . . . . 10
			6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
			8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
			9. Normative References . . . . . . . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
			Intellectual Property and Copyright Statements . . . . . . . . 15
			1. Conventions Used In This Document
	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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	this document are to be interpreted as described in [RFC-2119].		document are to be interpreted as described in RFC2119 [1].
	3. Introduction		2. Introduction
	Routers and destination hosts use the Internet Control Message		IP routers use the Internet Control Message Protocol (ICMP) [2] to
	Protocol (ICMP) [RFC-792] to convey control information to source		convey control information to source hosts. Network operators use
	hosts. Network operators use this information to diagnose routing		this information to diagnose routing problems.
	problems.
	Bonica, Tappan, Hwa Draft-Expires February 2001 1
	When a router receives an undeliverable IP datagram, it can send an		When a router receives an undeliverable IP datagram, it can send an
	ICMP message to the host that originated the datagram. The ICMP		ICMP message to the host that originated the datagram. The ICMP
	message indicates why the datagram could not be delivered. It also		message indicates why the datagram could not be delivered. It also
	contains the IP header and leading payload octets of the "original		contains the IP header and leading payload octets of the "original
	datagram".		datagram".
	In this document, the term "original datagram" refers to the		In this document, the term "original datagram" refers to the datagram
	datagram to which the ICMP message is a response.		to which the ICMP message is a response.
	MPLS Label Switching Routers (LSR) also use ICMP to convey control		MPLS Label Switching Routers (LSR) also use ICMP to convey control
	information to source hosts. Sections 2.3 and 2.4 of [ENCODE]		information to source hosts. Sections 2.3 and 2.4 of RFC 3032 [3]
	describe the interaction between MPLS and ICMP.		describe the interaction between MPLS and ICMP.
	When an LSR receives an undeliverable MPLS encapsulated datagram, it		When an LSR receives an undeliverable MPLS encapsulated datagram, it
	removes the entire MPLS label stack, exposing the previously		removes the entire MPLS label stack, exposing the previously
	encapsulated IP datagram. The LSR then submits the IP datagram to a		encapsulated IP datagram. The LSR then submits the IP datagram to an
	network-forwarding module for error processing. Error processing can		error processing module. Error processing can include ICMP message
	include ICMP message generation.		generation.
	The ICMP message indicates why the original datagram could not be		The ICMP message indicates why the original datagram could not be
	delivered. It also contains the IP header and leading octets of the		delivered. It also contains the IP header and leading octets of the
	original datagram.		original datagram.
	The ICMP message, however, includes no information regarding the		The ICMP message, however, contains no information regarding the MPLS
	MPLS label stack that encapsulated the original datagram when it		label stack that encapsulated the original datagram when it arrived
	arrived at the LSR. This omission is significant because the LSR		at the LSR. This omission is significant because the LSR would have
	would have routed the original datagram based upon information		routed the original datagram based upon information contained by the
	contained by the MPLS label stack.		MPLS label stack.
	The current memo proposes extensions to ICMP that permit an LSR to		This memo proposes extensions to ICMP that permit an LSR to append
	append MPLS label stack information to ICMP messages. ICMP messages		MPLS label stack information to ICMP messages. ICMP messages
	regarding MPLS encapsulated datagrams SHOULD include the MPLS label		regarding MPLS encapsulated datagrams SHOULD include the MPLS label
	stack, as it arrived at the router that is sending the ICMP message.		stack, as it arrived at the router that is sending the ICMP message.
	The ICMP message MUST also include the IP header and leading payload		The ICMP message MUST also include the IP header and leading payload
	octets of the original datagram.		octets of the original datagram.
	Network operators will use this information to diagnose routing		3. Application to TRACEROUTE
	problems.
	4. Motivation
	ICMP extensions defined in the current memo support enhancements to		ICMP extensions defined in this memo support enhancements to
	TRACEROUTE. The enhanced TRACEROUTE, like older implementations,		TRACEROUTE. The enhanced TRACEROUTE, like older implementations,
	indicates which nodes the original datagram visited en route to its		indicates which nodes the original datagram visited en route to its
	ultimate destination. It differs from older implementations in that		destination. It differs from older implementations in that it also
	it also indicates the original datagrams MPLS encapsulation status		indicates the original datagrams MPLS encapsulation status as it
	as it arrived at each node.		arrived at each node.
	Figure 1 contains sample output from an enhanced TRACEROUTE		Figure 1 contains sample output from an enhanced TRACEROUTE
	implementation.		implementation.
	Bonica,Tappan,Gan Draft-Expires February 2001 2		> traceroute 100.100.6.1
	>Traceroute 166.45.2.74
	traceroute to 166.45.2.74, 30 hops max, 40 byte packets
	1 166.45.5.1 1.281 ms 1.103 ms 1.096 ms
	2 166.45.4.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2001
	mplsExpBits1=0
	3 166.45.3.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2002
	mplsExpBits1=0
	4 166.45.6.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2003
	mplsExpBits1=0
	5 166.45.2.1 1.281 ms 1.103 ms 1.096 ms
	6 166.45.2.74 1.281 ms 1.103 ms 1.096 ms
	Figure 1. Enhanced TRACEROUTE sample output		traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets
	5. Disclaimer		1 10.1.1.2 (10.1.1.2) 0.661 ms 0.618 ms 0.579 ms
	The current memo does not define the general relationship between		2 10.1.12.2 (10.1.12.2) 0.861 ms 0.718 ms 0.679 ms
	ICMP and MPLS. Sections 2.3 and 2.4 of [ENCODE] define this
	relationship.
	Specifically, this document defers to [ENCODE] with respect to the		MPLS Label=100048 Exp=0 TTL=1 S=1
			3 10.1.24.2 (10.1.24.2) 0.822 ms 0.731 ms 0.708 ms
			MPLS Label=100016 Exp=0 TTL=1 S=1
			4 10.100.6.1 (10.100.6.1) 0.961 ms 8.676 ms 0.875 ms
			Figure 1: Enhanced TRACEROUTE Sample Output
			4. Disclaimer
			This memo does not define the general relationship between ICMP and
			MPLS. Sections 2.3 and 2.4 of RFC3032 define this relationship.
			Specifically, this document defers to RFC3032 with respect to the
	following issues:		following issues:
	- conditions upon which an LSR emits ICMP messages		- conditions upon which an LSR emits ICMP messages
	- handling of ICMP messages bound for hosts that are identified
	by private addresses		- handling of ICMP messages bound for hosts that are identified by
			private addresses
	The current memo does not define encapsulation specific TTL		The current memo does not define encapsulation specific TTL
	manipulation procedures. It defers to Section 10 of [MPLSATM] and		manipulation procedures. It defers to Section 5.4 of RFC 3034 [4]
	Section 5.4 of [MPLSFRAME] in this matter.		and Section 10 of RFC 3035 [5] in this matter.
	When encapsulation specific TTL manipulation procedures defeat the		When encapsulation specific TTL manipulation procedures defeat the
	basic TRACEROUTE mechanism, they will also defeat enhanced		basic TRACEROUTE mechanism, they will also defeat enhanced TRACEROUTE
	TRACEROUTE implementations.		implementations.
	The current memo does not address extensions to ICMPv6. These should		The current memo does not address extensions to ICMPv6. These should
	be addressed in a separate draft.		be addressed in a separate draft.
	6. Formal Syntax		5. Syntax
	This section defines a data structure that an LSR can append to		This section defines a data structure that an LSR can append to
	selected ICMP messages. The data structure contains the MPLS label		selected ICMP messages. The data structure contains the MPLS label
	stack that encapsulated the original datagram when it arrived at the		stack that encapsulated the original datagram when it arrived at the
	LSR.		LSR.
	The data structure defined herein can be appended to the following		In theory, the data structure defined herein can be appended to the
	ICMP message types:		following ICMP message types:
	Bonica,Tappan,Gan Draft-Expires February 2001 3		Destination Unreachable
	1) Destination Unreachable
	2) Time Exceeded		Time Exceeded
	3) Parameter Problem
	4) Source Quench		Parameter Problem
	5) Redirect
			Source Quench
			Redirect
			However, in practice, it would only be useful when appended to the
			Destination Unreachable and Time Exceeded messages.
	According to RFC-792, bytes 0 through 19 of any ICMP message contain		According to RFC-792, bytes 0 through 19 of any ICMP message contain
	a header whose format is analogous to that of the IP datagram. Bytes		a header whose format is analogous to that of the IP datagram. Bytes
	20 through 23 contain an ICMP message type, code and checksum. Bytes		20 through 23 contain an ICMP message type, code and checksum. Bytes
	24 through 27 contain message specific data.		24 through 27 contain message specific data.
	Also according to RFC-792, the final field contained by each of the		Also according to RFC-792, the final field contained by each of the
	ICMP message types listed above begins at byte 28. It reflects the		ICMP message types listed above begins at byte 28. It reflects the
	IP header and leading 64 bits of the original datagram. [RFC-1812]		IP header and leading 64 bits of the original datagram. RFC 1812 [6]
	recommends that this final field be extended to include as much of		recommends that this final field be extended to include as much of
	the original datagram as possible.		the original datagram as possible.
	When an LSR appends the data structure defined herein to an ICMP		When an LSR appends the data structure defined herein to an ICMP
	message, the final field of the ICMP message body MUST contain the		message, the final field of the ICMP message body MUST contain the
	first 128 octets of the original datagram. At least 20 of these 128		first 128 octets of the original datagram. At least 20 of these 128
	octets represent the IP header of the original datagram.		octets represent the IP header of the original datagram.
	If the original datagram was shorter than 128 octets, the final		If the original datagram was shorter than 128 octets, the final field
	field MUST be padded with 0's.		MUST be padded with 0's.
	When an LSR appends the data structure defined herein to an ICMP		When an LSR appends the data structure defined herein to an ICMP
	message, the ICMP "total length" MUST be equal to the data structure		message, the ICMP "total length" MUST be adjusted appropriately to
	length plus 156. The first octet of the data structure must be		include the data structure.
	displaced 156 octets from the beginning of the ICMP message.
	The data structure defined in this section consists of a common		The data structure defined in this section consists of a common
	header followed by object instances. Each object instance consists		header followed by object instances. Each object instance consists
	of an object header plus contents.		of an object header plus contents.
	Currently, two object classes are defined. One object class contains		Currently, two object classes are defined. One object class contains
	an entire MPLS label stack, formatted exactly as it was when it		an entire MPLS label stack, formatted exactly as it was when it
	arrived at the LSR that sends the ICMP message. The other contains		arrived at the LSR that sends the ICMP message. The other contains
	some portion of the original datagram that could not be included in		some portion of the original datagram that could not be included in
	the final field of the ICMP message body (i.e., the octet 129 and		the final field of the ICMP message body (i.e., the octet 129 and
	beyond).		beyond).
	Both object classes are optional.		Both object classes are optional.
	In the future, additional object classes may be defined.		In the future, additional object classes may be defined.
	Bonica,Tappan,Gan Draft-Expires February 2001 4		5.1 Common Header
	6.1 Common Header
	0 1 2 3		0 1 2 3
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	| Vers | (Reserved) | Checksum |		| Vers | (Reserved) | Checksum |
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
			Figure 2: Common Header
	The fields in the common header are as follows:		The fields in the common header are as follows:
	Vers: 4 bits		Vers: 4 bits
	ICMP extension version number.		ICMP extension version number. This is version 2.
	This is version 2.
	Checksum: 16 bits		Checksum: 16 bits
	The one's complement of the one's complement sum of the data		The one's complement of the one's complement sum of the data
	structure, with the checksum field replaced by zero for the purpose		structure, with the checksum field replaced by zero for the
	of computing the checksum. An all-zero value means that no checksum		purpose of computing the checksum. An all-zero value means that
	was transmitted.		no checksum was transmitted.
	If the checksum field contains a value other than described above,		If the checksum field contains a value other than described above,
	the ICMP message does not include the extensions described in this		the ICMP message does not include the extensions described in this
	memo. This, however, does not imply that the ICMP message is		memo. This, however, does not imply that the ICMP message is
	malformed. It may be in strict compliance with RFC-1812.		malformed. It may be in strict compliance with RFC-1812.
	Reserved: Must be set to 0.		Reserved: Must be set to 0.
	6.2 Object Header		5.2 Object Header
	Every object consists of one or more 32-bit words with a one-word		Every object consists of one or more 32-bit words with a one-word
	header, with the following format:		header. The following is the format of the one-word header:
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	| Length | Class-Num | C-Type |		| Length | Class-Num | C-Type |
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	| |		| |
	| // (Object contents) // |		| // (Object contents) // |
	| |		| |
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
			Figure 3: Object Header
	An object header has the following fields:		An object header has the following fields:
	Length: 16 bits		Length: 16 bits
	Length of the object, measured in octets, including the object		Length of the object, measured in octets, including the object
	header and object contents.		header and object contents.
	Bonica,Tappan,Gan Draft-Expires February 2001 5
	Class-Num: 8 bits		Class-Num: 8 bits
	Identifies object class.		Identifies object class.
	C-Type: 8 bits		C-Type: 8 bits
	Identifies object sub-type.		Identifies object sub-type.
	6.3 MPLS Stack Entry Object Class		5.3 MPLS Stack Entry Object Class
	A single instance of the MPLS Entry Object class represents the		A single instance of the MPLS Entry Object class represents the
	entire MPLS label stack, formatted exactly as it was when it arrived		entire MPLS label stack, formatted exactly as it was when it arrived
	at the LSR that sends the ICMP message		at the LSR that sends the ICMP message
	In the illustration below, octets 0-3 depict the first member of the		In the illustration below, octets 0-3 depict the first member of the
	MPLS label stack. Each remaining member of the MPLS label stack is		MPLS label stack. Each remaining member of the MPLS label stack is
	represented by another 4 octets that share the same format.		represented by another 4 octets that share the same format.
	Syntax follows:		Syntax follows:
	skipping to change at line 277		skipping to change at page 10, line 14
	0 1 2 3		0 1 2 3
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	| Label |EXP |S| TTL |		| Label |EXP |S| TTL |
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	| |		| |
	| // Remaining MPLS Stack Entries // |		| // Remaining MPLS Stack Entries // |
	| |		| |
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
			Figure 4: MPLS Stack Entry Object Class
	Label: 20 bits		Label: 20 bits
	Exp: Experimental Use, 3 bits		Exp: Experimental Use, 3 bits
	S: Bottom of Stack, 1 bit		S: Bottom of Stack, 1 bit
	TTL: Time to Live, 8 bits		TTL: Time to Live, 8 bits
	6.4 Extended Payload Object Class		5.4 Extended Payload Object Class
	An instance of the Extended Payload Object class represents some		An instance of the Extended Payload Object class represents some
	portion of the original datagram that could not be fit in the final		portion of the original datagram that could not be fit in the final
	field of the ICMP message body (i.e., octets beyond 128).		field of the ICMP message body (i.e., octets beyond 128).
	Bonica,Tappan,Gan Draft-Expires February 2001 6
	Syntax follows:		Syntax follows:
	MPLS Stack Entry Class = 2, C-Type = 1.		MPLS Stack Entry Class = 2, C-Type = 1.
	0 1 2 3		0 1 2 3
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	| |		| |
	| // Additional bytes of original datagram // |		| // Additional bytes of original datagram // |
	| |		| |
	+-------------+-------------+-------------+-------------+		+-------------+-------------+-------------+-------------+
	7. Backward Compatibility		Figure 5: Extended Payload Object Class
	ICMP extensions proposed in this document MUST be backward		6. Backward Compatibility
	compatible with the syntax described in RFC-792. Extensions proposed
	in this memo MUST NOT change or deprecate any field defined in RFC-		ICMP extensions proposed in this document MUST be backward compatible
	792.		with the syntax described in RFC-792. Extensions proposed in this
			memo MUST NOT change or deprecate any field defined in RFC-792.
	The extensions defined herein are in keeping with the spirit, if not		The extensions defined herein are in keeping with the spirit, if not
	the letter of RFC-1812. In order to support IP-in-IP tunneling, RFC-		the letter of RFC-1812. In order to support IP-in-IP tunneling, RFC-
	1812 extends the final field of selected ICMP messages to include a		1812 extends the final field of selected ICMP messages to include a
	greater portion of the original datagram. Unfortunately, it extends		greater portion of the original datagram. Unfortunately, it extends
	this field to a variable length without adding a length attribute.		this field to a variable length without adding a length attribute.
	This memo binds the length of that final field to an arbitrarily		This memo binds the length of that final field to an arbitrarily
	large value (128 octets). Fixing the length of that field		large value (128 octets). Fixing the length of that field
	facilitates extension of the ICMP message. An additional object is		facilitates extension of the ICMP message. An additional object is
	provided through which octets 129 and beyond can be appended to the		provided through which octets 129 and beyond can be appended to the
	ICMP message.		ICMP message.
	As few datagrams contain L3 or L4 header information beyond octet		As few datagrams contain L3 or L4 header information beyond octet
	128, it is unlikely that the extensions described herein will		128, it is unlikely that the extensions described herein will disable
	disable any applications that rely upon RFC-1812 style ICMP		any applications that rely upon RFC-1812 style ICMP messages.
	messages.
	8. Security Considerations		7. Security Considerations
	This memo presents no security considerations beyond those already		This memo presents no security considerations beyond those already
	presented by current ICMP applications (e.g., traceroute).		presented by current ICMP applications (e.g., traceroute).
	9. References		8. IANA Considerations
	[ARCH], Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		IANA should establish a registry of ICMP extention classes and class-
	Label Switching Architecture", Internet Draft <draft-ietf-mpls-arch-		sub-types.
	06.txt>, August, 1999
	Bonica,Tappan,Gan Draft-Expires February 2001 7		9. Normative References
	[ENCODE], Rosen, E., Rekhter, Y., Tappan, D, Farinacci, D.,
	Fedorkow, G., Li, T., Conta, A., "MPLS Stack Encoding", Internet
	Draft, <draft-ietf-mpls-label-encapse-07.txt>, September 1999.
	[MPLSATM], Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y.,		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Rosen, E., Swallow, G, "MPLS using LDP and ATM VC Switching",		Levels", BCP 14, RFC 2119, March 1997.
	<draft-ietf- mpls-atm-04.txt>, June 2000.
	[MPLSFRAME], Conta, A., Doolan, P., Malis, A., "Use of Label		[2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
	Switching on Frame Relay Networks", <draft-ietf-mpls-fr-06.txt>,		September 1981.
	June, 2000.
	[RFC-792], Postel, J., "Internet Control Message Protocol", RFC 792,		[3] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D.,
	ISI, September 1981.		Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
			January 2001.
	[RFC-1812], Baker, F., "Requirements for IP Version 4 Routers", RFC		[4] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on
	1812, June 1995.		Frame Relay Networks Specification", RFC 3034, January 2001.
	[RFC-2026], Bradner, S., "Internet Standards Process Revision 3",		[5] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G.,
	RFC 2026, Harvard University, October 1996.		Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC
			Switching", RFC 3035, January 2001.
	[RFC-2119], Bradner, S,, "Key words for use in RFCs to Indicate		[6] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
	Requirement Levels", RFC 2119, Harvard University, March 1997		June 1995.
	10. Acknowledgments		Authors' Addresses
	Thanks to Yakov Rekhter and Mike Heard for their contributions to		Ronald P. Bonica
	this memo.		Juniper Networks
			2251 Corporate Park Drive
			Herndon, VA 20171
			US
	11. Author's Addresses		Email: rbonica@juniper.net
	Ronald P. Bonica		Der-Hwa Gan
	MCI WorldCom		Juniper Networks
	22001 Loudoun County Pkwy		1194 N. Mathilda Ave.
	Ashburn, Virginia, 20147		Sunnyvale, CA 94089
	Phone: 703 886 1681		US
	Email: rbonica@mci.net
			Email: dhg@juniper.net
	Daniel C. Tappan		Daniel C. Tappan
	Cisco Systems		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, Massachusetts, 01824		Chelmsford, MA 01824
			US
	Email: tappan@cisco.com		Email: tappan@cisco.com
	Der-Hwa Gan		Intellectual Property Statement
	Juniper Networks
	385 Ravendale Drive
	Mountain View, California 94043
	Bonica,Tappan,Gan Draft-Expires February 2001 8
	Email: dhg@juniper.net
	Bonica,Tappan,Gan Draft-Expires February 2001 9		The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
	Full Copyright Statement		Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	"Copyright (C) The Internet Society (date). All Rights Reserved.		The IETF invites any interested party to bring to its attention any
	This document and translations of it may be copied and furnished to		copyrights, patents or patent applications, or other proprietary
	others, and derivative works that comment on or otherwise explain it		rights that may cover technology that may be required to implement
	or assist in its implmentation may be prepared, copied, published		this standard. Please address the information to the IETF at
	and distributed, in whole or in part, without restriction of any		ietf-ipr@ietf.org.
	kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into
	Bonica,Tappan,Gan Draft-Expires February 2001 10		Disclaimer of Validity
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Copyright Statement
			Copyright (C) The Internet Society (2005). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
			Acknowledgment
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/