< draft-meyer-gre-update-01.txt		draft-meyer-gre-update-02.txt >
	Network Working Group Dino Farinacci		Network Working Group Dino Farinacci
	Internet Draft Tony Li		Internet Draft Tony Li
	Category Procket Networks		Procket Networks
	Stan Hanks		Stan Hanks
	Enron Communications		Enron Communications
	David Meyer		David Meyer
	Cisco Systems		Cisco Systems
	Paul Traina		Paul Traina
	Juniper Networks		Juniper Networks
	Category Standards Track		Category Standards Track
	draft-meyer-gre-update-01.txt December, 1999		draft-meyer-gre-update-02.txt January, 2000
	Generic Routing Encapsulation (GRE)		Generic Routing Encapsulation (GRE)
	<draft-meyer-gre-update-01.txt>		<draft-meyer-gre-update-02.txt>
	1. Status of this Memo		1. 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 RFC 2026.		all provisions of Section 10 of RFC 2026.
	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
	other groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-Drafts.
	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
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	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.
	2. Abstract		2. Abstract
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	network layer protocol over another arbitrary network layer protocol.		network layer protocol over another arbitrary network layer protocol.
	3. Copyright Notice		3. Copyright Notice
	Copyright (C) The Internet Society (1999). All Rights Reserved		Copyright (C) The Internet Society (1999). All Rights Reserved
	4. Introduction		4. Introduction
	A number of different proposals [RFC1234, RFC1226] currently exist		A number of different proposals [RFC1234, RFC1226] currently exist
	for the encapsulation of one protocol over another protocol. Other		for the encapsulation of one protocol over another protocol. Other
	types of encapsulations [RFC1241, SDRP, RFC1479] have been proposed		types of encapsulations [RFC1241, RFC1479] have been proposed for
	for transporting IP over IP for policy purposes. This memo describes		transporting IP over IP for policy purposes. This memo describes a
	a protocol which is very similar to, but is more general than, the		protocol which is very similar to, but is more general than, the
	above proposals. In attempting to be more general, many protocol		above proposals. In attempting to be more general, many protocol
	specific nuances have been ignored. The result is that this proposal		specific nuances have been ignored. The result is that this proposal
	may be less suitable for a situation where a specific "X over Y"		may be less suitable for a situation where a specific "X over Y"
	encapsulation has been described. It is the intent of this protocol
	to provide a simple, general purpose mechanism which reduces the
	problem of encapsulation from its current O(n^2) problem to a more		problem of encapsulation from its current O(n^2) problem to a more
	manageable state. This memo purposely does not address the issue of		manageable state. This memo purposely does not address the issue of
	when a packet should be encapsulated. This memo acknowledges, but		when a packet should be encapsulated. This memo acknowledges, but
	does not address problems such as mutual encapsulation [RFC1326].		does not address problems such as mutual encapsulation [RFC1326].
	In the most general case, a system has a packet that needs to be		In the most general case, a system has a packet that needs to be
	encapsulated and delivered to some destination. We will call this		encapsulated and delivered to some destination. We will call this
	the payload packet. The payload is first encapsulated in a GRE		the payload packet. The payload is first encapsulated in a GRE
	packet. The resulting GRE packet can then be encapsulated in some		packet. The resulting GRE packet can then be encapsulated in some
	other protocol and then forwarded. We will call this outer protocol		other protocol and then forwarded. We will call this outer protocol
	the delivery protocol. The algorithms for processing this packet are		the delivery protocol. The algorithms for processing this packet are
	discussed later.		discussed later.
	The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,		The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
	SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined		SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
	in RFC 2119 [RFC2119].		in RFC 2119 [RFC2119].
	4.1. Overall packet		5. Structure of a GRE Encapsulated Packet
	A GRE encapsulated packet has the form:		A GRE encapsulated packet has the form:
	---------------------------------		---------------------------------
	| |		| |
	| Delivery Header |		| Delivery Header |
	| |		| |
	---------------------------------		---------------------------------
	| |		| |
	| GRE Header |		| GRE Header |
	| |		| |
	---------------------------------		---------------------------------
	| |		| |
	| Payload packet |		| Payload packet |
	| |		| |
	---------------------------------		---------------------------------
	4.2. Packet header		This specification is generally concerned with the structure of the
			GRE header, although special consideration is given to some of the
			issues surrounding IPv4 payloads.
			5.1. GRE Header
	The GRE packet header has the form:		The GRE packet header has the form:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|C| Reserved0 | Ver | Protocol Type |		|C| Reserved0 | Ver | Protocol Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Checksum (optional) | Reserved1 (Optional) |		| Checksum (optional) | Reserved1 (Optional) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	4.3. Checksum Present (bit 0)		5.2. Checksum Present (bit 0)
	If the Checksum Present bit is set to one, then the Checksum and the		If the Checksum Present bit is set to one, then the Checksum and the
	Reserved1 fields are present and the Checksum field contains valid		Reserved1 fields are present and the Checksum field contains valid
	information. Note that a compliant implementation MUST accept and		information. Note that a compliant implementation MUST accept and
	process the these fields.		process this field.
	4.4. Reserved0 (bits 1-12)		5.3. Reserved0 (bits 1-12)
	Bits 1 through 12 are reserved for future use. A sender MUST set them		Bits 1 through 12 are reserved for future use. A sender MUST set them
	to zero while a recipient MUST be prepared to deal with non-zero data		to zero while a recipient MUST be prepared to deal with non-zero data
	as specified in section 7.		as specified in section 7.
	4.4.1. Version Number (bits 13-15)		5.3.1. Version Number (bits 13-15)
	The Version Number field MUST contain the value zero.		The Version Number field MUST contain the value zero.
	4.5. Protocol Type (2 octets)		5.4. Protocol Type (2 octets)
	The Protocol Type field contains the protocol type of the payload		The Protocol Type field contains the protocol type of the payload
	packet. These Protocol Types are defined in [RFC1700] as "ETHER		packet. These Protocol Types are defined in [RFC1700] as "ETHER
	TYPES" and in [ETYPES]. An implementation receiving a packet		TYPES" and in [ETYPES]. An implementation receiving a packet
	containing a Protocol Type which is not listed in [RFC1700] or		containing a Protocol Type which is not listed in [RFC1700] or
	[ETYPES] SHOULD discard the packet.		[ETYPES] SHOULD discard the packet.
	4.6. Checksum (2 octets)		5.5. Checksum (2 octets)
	The Checksum field contains the IP (one's complement) checksum sum of		The Checksum field contains the IP (one's complement) checksum sum of
	the all the 16 bit words in the GRE header and the payload packet.		the all the 16 bit words in the GRE header and the payload packet.
	For purposes of computing the checksum, the value of the checksum		For purposes of computing the checksum, the value of the checksum
	field is zero. This field is present only if the Checksum Present bit		field is zero. This field is present only if the Checksum Present bit
	is set to one.		is set to one.
	4.7. Reserved1 (2 octets)		5.6. Reserved1 (2 octets)
	The Reserved1 field is reserved for future use, and if present, MUST		The Reserved1 field is reserved for future use, and if present, MUST
	be transmitted as zero. The Reserved1 field is present only when the		be transmitted as zero. The Reserved1 field is present only when the
	Checksum field is present (that is, Checksum Present bit is set to		Checksum field is present (that is, Checksum Present bit is set to
	one).		one).
	5. IPv4 as a Payload		6. IPv4 as a Payload
	When IPv4 is being carried as the GRE payload, the Protocol Type		When IPv4 is being carried as the GRE payload, the Protocol Type
	field MUST be set to 0x800.		field MUST be set to 0x800.
	5.1. Forwarding IPv4 Payload Packets		6.1. Forwarding Decapsulated IPv4 Payload Packets
	When a tunnel endpoint decapsulates a GRE packet which has an IPv4		When a tunnel endpoint decapsulates a GRE packet which has an IPv4
	packet as the payload, the destination address in the IPv4 payload		packet as the payload, the destination address in the IPv4 payload
	packet header MUST be used to forward the packet and the TTL of the		packet header MUST be used to forward the packet and the TTL of the
	payload packet MUST be decremented. Care should be taken when		payload packet MUST be decremented. Care should be taken when
	forwarding such a packet, since if the destination address of the		forwarding such a packet, since if the destination address of the
	payload packet is the encapsulator of the packet (i.e., the other end		payload packet is the encapsulator of the packet (i.e., the other end
	of the tunnel), looping can occur. In this case, the packet MUST be		of the tunnel), looping can occur. In this case, the packet MUST be
	discarded.		discarded.
	6. IPv4 as a Delivery Protocol		7. IPv4 as a Delivery Protocol
	The IPv4 protocol 47 [RFC1700] is used when GRE packets are		The IPv4 protocol 47 [RFC1700] is used when GRE packets are
	enapsulated in IPv4. See [RFC1122] for requirements relating to the		enapsulated in IPv4. See [RFC1122] for requirements relating to the
	delivery of packets over IPv4 networks.		delivery of packets over IPv4 networks.
	7. Interoperation with RFC 1701 Compliant Implementations		8. Interoperation with RFC 1701 Compliant Implementations
	In RFC 1701, the field described here as Reserved0 contained a number		In RFC 1701, the field described here as Reserved0 contained a number
	of flag bits which this specification deprecates. In particular, the		of flag bits which this specification deprecates. In particular, the
	Routing Present, Key Present, Sequence Number Present, and Strict		Routing Present, Key Present, Sequence Number Present, and Strict
	Source Route bits have been deprecated, along with the Recursion		Source Route bits have been deprecated, along with the Recursion
	Control field. As a result, the GRE header will never contain the		Control field. As a result, the GRE header will never contain the
	Key, Sequence Number or Routing fields specified in RFC 1701.		Key, Sequence Number or Routing fields specified in RFC 1701.
	There are, however, existing implementations of the Informational RFC		There are, however, existing implementations of the RFC 1701. The
	1701. The following sections describe correct interoperation with		following sections describe correct interoperation with such
	such implementations.		implementations.
	7.1. RFC 1701 Compliant Receiver		8.1. RFC 1701 Compliant Receiver
	An implementation complying to this specification will transmit the		An implementation complying to this specification will transmit the
	Reserved0 field set to zero. An RFC 1701 compliant receiver will		Reserved0 field set to zero. An RFC 1701 compliant receiver will
	interpret this as having the Routing Present, Key Present, Sequence		interpret this as having the Routing Present, Key Present, Sequence
	Number Present, and Strict Source Route bits set to zero, and will		Number Present, and Strict Source Route bits set to zero, and will
	not expect the RFC 1701 Key, Sequence Number or Routing fields to be		not expect the RFC 1701 Key, Sequence Number or Routing fields to be
	present.		present.
	7.2. RFC 1701 Compliant Transmitter		8.2. RFC 1701 Compliant Transmitter
	An RFC 1701 transmitter may set any of the Routing Present, Key		An RFC 1701 transmitter may set any of the Routing Present, Key
	Present, Sequence Number Present, and Strict Source Route bits set to		Present, Sequence Number Present, and Strict Source Route bits set to
	one, and thus may transmit the RFC 1701 Key, Sequence Number or		one, and thus may transmit the RFC 1701 Key, Sequence Number or
	Routing fields in the GRE header. In this case, an implementation		Routing fields in the GRE header. In this case, an implementation
	compliant with this specification MAY discard the packet.		compliant with this specification MAY discard the packet.
	8. Security Considerations		9. Security Considerations
	Security in a network using GRE should be relatively similar to		Security in a network using GRE should be relatively similar to
	security in a normal IPv4 network, as routing using GRE follows the		security in a normal IPv4 network, as routing using GRE follows the
	same routing that IPv4 uses natively. Route filtering will remain		same routing that IPv4 uses natively. Route filtering will remain
	unchanged. However packet filtering requires either that a firewall		unchanged. However packet filtering requires either that a firewall
	look inside the GRE packet or that the filtering is done on the GRE		look inside the GRE packet or that the filtering is done on the GRE
	tunnel endpoints. In those environments in which this is considered		tunnel endpoints. In those environments in which this is considered
	to be a security issue it may be desirable to terminate the tunnel at		to be a security issue it may be desirable to terminate the tunnel at
	the firewall.		the firewall.
	9. IANA Considerations for Assignment of Protocol Types		10. IANA Considerations for Assignment of Protocol Types
	New ETHER TYPES as assigned by Xerox Systems Institute [RFC1700]. The		New ETHER TYPES as assigned by Xerox Systems Institute [RFC1700]. The
	IANA SHOULD NOT encourage the assignment of additional ETHER TYPES		IANA SHOULD NOT encourage the assignment of additional ETHER TYPES
	(GRE Protocol Types) for use with GRE.		(GRE Protocol Types) for use with GRE.
	10. Acknowledgments		11. Acknowledgments
	This document is derived from the original ideas of the authors of		This document is derived from the original ideas of the authors of
	RFC 1701 and RFC 1702. Brian Carpenter, Bill Fenner, Thomas Narten,		RFC 1701 and RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush,
	Dave Thaler, Andy Malis, Randy Bush, Scott Bradner and Hitoshi Asaeda		Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, and Dave
	provided many constructive and insightful comments.		Thaler and provided many constructive and insightful comments.
	11. Appendix -- Known Issues		12. Appendix -- Known Issues
	This document specifies the behavior of currently deployed GRE		This document specifies the behavior of currently deployed GRE
	implementations. As such, it does not attempt to address the		implementations. As such, it does not attempt to address the
	following known issues:		following known issues:
	11.1. Interaction Path MTU Discovery (PMTU) [RFC1191]		12.1. Interaction Path MTU Discovery (PMTU) [RFC1191]
	An important issue here is that blackholes can arise if PMTU is used		Existing implementations of GRE, when using IPv4 as the Delivery
	and the tunnel entry does not relay errors back to the originator of		Header, do not implement Path MTU discovery and do not set the Don't
	the packet. The black hole is realized by the following behavior: the		Fragment bit in the Delivery Header. This can cause large packets to
	originator sets the don't fragment bit in the delivery header, the		become fragmented within the tunnel and reassembled at the tunnel
	packet gets dropped within the tunnel, but since the originator		exit (independent of whether the payload packet is using PMTU). If a
	doesn't receive feedback, it retransmits with the same PMTU, causing		tunnel entry point were to use Path MTU discovery, however, that
	subsequently transmitted packets to be dropped.		tunnel entry point would also need to relay ICMP unreachable error
			messages (in particular the "fragmentation needed and DF set" code)
			back to the originator of the packet, which is not a requirement in
			this specification. Failure to properly relay Path MTU information to
			an originator can result in the following behavior: the originator
			sets the don't fragment bit, the packet gets dropped within the
			tunnel, but since the originator doesn't receive proper feedback, it
			retransmits with the same PMTU, causing subsequently transmitted
			packets to be dropped.
	11.2. IPv6 as Delivery and/or Payload Protocol		12.2. IPv6 as Delivery and/or Payload Protocol
	This specification describes the intersection of GRE currently		This specification describes the intersection of GRE currently
	deployed by multiple vendors. IPv6 as delivery and/or payload		deployed by multiple vendors. IPv6 as delivery and/or payload
	protocol is not included in the currently deployed versions of GRE.		protocol is not included in the currently deployed versions of GRE.
	11.3. Interaction with ICMP		12.3. Interaction with ICMP
	11.4. Interaction with the Differentiated Services Architecture
	11.5. Multiple and Looping Encapsulations
	12. References
	[ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers
	[RFC1122] R.T. Braden, "Requirements for Internet hosts -		12.4. Interaction with the Differentiated Services Architecture
	communication layers", RFC1122, Octber 1989
	[RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery",		12.5. Multiple and Looping Encapsulations
	RFC 1191, November 1990.		13. REFERENCES
	[RFC1226] Kantor, B. "Internet Protocol Encapsulation of AX.25		[ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers
	Frames", RFC 1226, University of California, San Diego,
	May 1991.
	[RFC1234] Provan, D. "Tunneling IPX Traffic through IP Networks",		[RFC1122] R.T. Braden, "Requirements for Internet hosts -
	RFC 1234, Novell, Inc., June 1991.		communication layers", RFC1122, Octber 1989
	[RFC1241] Woodburn, R., and D. Mills, "Scheme for an Internet		[RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery",
	Encapsulation Protocol: Version 1", RFC 1241, SAIC,		RFC 1191, November 1990.
	University of Delaware, July 1991.
	[RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered		[RFC1226] Kantor, B. "Internet Protocol Encapsulation of AX.25
	Dangerous", RFC 1326, Bellcore, May 1992.		Frames", RFC 1226, University of California, San Diego,
			May 1991.
	[RFC1479] Steenstrup, M. "Inter-Domain Policy Routing Protocol		[RFC1234] Provan, D. "Tunneling IPX Traffic through IP Networks",
	Specification: Version 1", RFC 1479, BBN Systems and		RFC 1234, Novell, Inc., June 1991.
	Technologies, July 1993.
	[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers",		[RFC1241] Woodburn, R., and D. Mills, "Scheme for an Internet
	RFC 1700, October 1994.		Encapsulation Protocol: Version 1", RFC 1241, SAIC,
			University of Delaware, July 1991.
	[RFC1701] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic		[RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered
	Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and		Dangerous", RFC 1326, Bellcore, May 1992.
	cisco Systems, October 1994.
	[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina,		[RFC1479] Steenstrup, M. "Inter-Domain Policy Routing Protocol
	"Generic Routing Encapsulation over IPv4 networks",		Specification: Version 1", RFC 1479, BBN Systems and
	RFC 1702, NetSmiths, Ltd., cisco Systems, October 1994.		Technologies, July 1993.
	[RFC2003] C. Perkins, "IP Encapsulation within IP", RFC 2003,		[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers",
	October, 1996.		RFC 1700, October 1994.
	[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate		[RFC1701] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic
	Requirement Levels", RFC 2119, March, 1997.		Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and
			cisco Systems, October 1994.
	[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J.		[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina,
	Turner, "Internet Security Association and Key		"Generic Routing Encapsulation over IPv4 networks",
	Management Protocol (ISAKMP)", RFC 2408, November		RFC 1702, NetSmiths, Ltd., cisco Systems, October 1994.
	1998.
	[RFC2473] A. Conta and S. Deering, "Generic Packet Tunneling in		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
	IPv6 Specification", RFC 2473, December, 1998.		Requirement Levels", RFC 2119, March, 1997.
	[SDRP] Estrin, D., Li, T., and Y. Rekhter, "Source Demand		[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J.
	Routing Protocol Specification (Version 1)", Work in		Turner, "Internet Security Association and Key
	Progress.		Management Protocol (ISAKMP)", RFC 2408, November
			1998.
	13. Authors' Addresses		14. Authors' Addresses
	Dino Farinacci		Dino Farinacci
	Procket Networks		Procket Networks
	3850 No. First St., Ste. C		3850 No. First St., Ste. C
	San Jose, CA 95134		San Jose, CA 95134
	Email: dino@procket.com		Email: dino@procket.com
	Tony Li		Tony Li
	Procket Networks		Procket Networks
	3850 No. First St., Ste. C		3850 No. First St., Ste. C
End of changes. 49 change blocks.
	94 lines changed or deleted		93 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/