< draft-ietf-nvo3-vmm-00.txt		draft-ietf-nvo3-vmm-01.txt >
	Network Working Group B. Sarikaya		Network Working Group B. Sarikaya
	Internet-Draft L. Dunbar		Internet-Draft
	Intended status: Best Current Practice Huawei USA		Intended status: Best Current Practice L. Dunbar
	Expires: January 18, 2018 B. Khasnabish		Expires: May 3, 2018 Huawei USA
			B. Khasnabish
	ZTE (TX) Inc.		ZTE (TX) Inc.
	T. Herbert		T. Herbert
	Quantonium		Quantonium
	S. Dikshit		S. Dikshit
	Cisco Systems		Cisco Systems
	July 17, 2017		October 30, 2017
	Virtual Machine Mobility Protocol for L2 and L3 Overlay Networks		Virtual Machine Mobility Protocol for L2 and L3 Overlay Networks
	draft-ietf-nvo3-vmm-00.txt		draft-ietf-nvo3-vmm-01.txt
	Abstract		Abstract
	This document describes a virtual machine mobility protocol commonly		This document describes a virtual machine mobility protocol commonly
	used in data centers built with overlay-based network virtualization		used in data centers built with overlay-based network virtualization
	approach. For layer 2, it is based on using a Network Virtualization		approach. For layer 2, it is based on using a Network Virtualization
	Authority (NVA)-Network Virtualization Edge (NVE) protocol to update		Authority (NVA)-Network Virtualization Edge (NVE) protocol to update
	Address Resolution Protocol (ARP) table or neighbor cache entries at		Address Resolution Protocol (ARP) table or neighbor cache entries at
	the NVA and the source NVEs tunneling in-flight packets to the		the NVA and the source NVEs tunneling in-flight packets to the
	destination NVE after the virtual machine moves from source NVE to		destination NVE after the virtual machine moves from source NVE to
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 38 ¶
	connection migration after the move.		connection migration after the move.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on January 18, 2018.		This Internet-Draft will expire on May 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	skipping to change at page 3, line 12 ¶		skipping to change at page 3, line 12 ¶
	arises for connectivity between Layer 2 boundaries which can be		arises for connectivity between Layer 2 boundaries which can be
	achieved by the network virtualization edge (NVE) functioning as		achieved by the network virtualization edge (NVE) functioning as
	Layer 3 gateway routing across bridging domain such as in Warehouse		Layer 3 gateway routing across bridging domain such as in Warehouse
	Scale Computers (WSC).		Scale Computers (WSC).
	Virtualization which is being used in almost all of today's data		Virtualization which is being used in almost all of today's data
	centers enables many virtual machines to run on a single physical		centers enables many virtual machines to run on a single physical
	computer or compute server. Virtual machines (VM) need hypervisor		computer or compute server. Virtual machines (VM) need hypervisor
	running on the physical compute server to provide them shared		running on the physical compute server to provide them shared
	processor/memory/storage. Network connectivity is provided by the		processor/memory/storage. Network connectivity is provided by the
	network virtualization edge (NVE) [I-D.ietf-nvo3-arch],		network virtualization edge (NVE) [RFC8014]. Being able to move VMs
	[I-D.ietf-nvo3-nve-nva-cp-req]. Being able to move VMs dynamically,		dynamically, or live migration, from one server to another allows for
	or live migration, from one server to another allows for dynamic load		dynamic load balancing or work distribution and thus it is a highly
	balancing or work distribution and thus it is a highly desirable		desirable feature [RFC7364].
	feature [RFC7364].
	There are many challenges and requirements related to migration,		There are many challenges and requirements related to migration,
	mobility, and interconnection of Virtual Machines (VMs)and Virtual		mobility, and interconnection of Virtual Machines (VMs)and Virtual
	Network Elements (VNEs). Retaining IP addresses after a move is a		Network Elements (VNEs). Retaining IP addresses after a move is a
	key requirement [RFC7364]. Such a requirement is needed in order to		key requirement [RFC7364]. Such a requirement is needed in order to
	maintain existing transport connections.		maintain existing transport connections.
	In L3 based data networks, retaining IP addresses after a move is		In L3 based data networks, retaining IP addresses after a move is
	simply not possible. This introduces complexity in IP address		simply not possible. This introduces complexity in IP address
	management and as a result transport connections need to be		management and as a result transport connections need to be
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 39 ¶
	there is a desire to define a standard control plane protocol for		there is a desire to define a standard control plane protocol for
	virtual machine mobility. The protocol should be based on IPv4 or		virtual machine mobility. The protocol should be based on IPv4 or
	IPv6. In this document we specify such a protocol for Layer 2 and		IPv6. In this document we specify such a protocol for Layer 2 and
	Layer 3 data networks.		Layer 3 data networks.
	2. Conventions and Terminology		2. Conventions and Terminology
	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 [RFC2119] and		document are to be interpreted as described in RFC 2119 [RFC2119] and
	[I-D.ietf-nvo3-arch].		[RFC8014].
	This document uses the terminology defined in [RFC7364]. In addition		This document uses the terminology defined in [RFC7364]. In addition
	we make the following definitions:		we make the following definitions:
	Tasks. Tasks are the generalization of virtual machines. Tasks in		Tasks. Tasks are the generalization of virtual machines. Tasks in
	containers that can be migrated correspond to the virtual machines		containers that can be migrated correspond to the virtual machines
	that can be migrated. We use task and virtual machine		that can be migrated. We use task and virtual machine
	interchangeably in this document.		interchangeably in this document.
	Hot VM Mobility. A given VM could be moved from one server to		Hot VM Mobility. A given VM could be moved from one server to
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 19 ¶
	may not contain the exact same data (state information)		may not contain the exact same data (state information)
	Cold VM Mobility. A given VM could be moved from one server to		Cold VM Mobility. A given VM could be moved from one server to
	another in stopped or suspended state.		another in stopped or suspended state.
	Source NVE refers to the old NVE where packets were forwarded to		Source NVE refers to the old NVE where packets were forwarded to
	before migration.		before migration.
	Destination NVE refers to the new NVE after migration.		Destination NVE refers to the new NVE after migration.
			Packets in flight refers to the packets received by the source NVE
			sent by the correspondents that have old ARP or neighbor cache entry
			before VM or task migration.
	3. Requirements		3. Requirements
	This section states requirements on data center network virtual		This section states requirements on data center network virtual
	machine mobility.		machine mobility.
	Data center network SHOULD support virtual machine mobility in IPv6.		Data center network SHOULD support virtual machine mobility in IPv6.
	IPv4 SHOULD also be supported in virtual machine mobility.		IPv4 SHOULD also be supported in virtual machine mobility.
	Virtual machine mobility protocol MAY support host routes to		Virtual machine mobility protocol MAY support host routes to
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 31 ¶
	new destination one. During this period, a tunnel is needed so that		new destination one. During this period, a tunnel is needed so that
	source NVE forwards packets to the destination NVE.		source NVE forwards packets to the destination NVE.
	In IPv4, the virtual machine immediately after the move sends a		In IPv4, the virtual machine immediately after the move sends a
	gratuitous ARP request message containing its IPv4 and Layer 2 or MAC		gratuitous ARP request message containing its IPv4 and Layer 2 or MAC
	address in its new NVE, destination NVE. This message's destination		address in its new NVE, destination NVE. This message's destination
	address is the broadcast address. NVE receives this message. NVE		address is the broadcast address. NVE receives this message. NVE
	should update VM's ARP entry in the central directory at the NVA.		should update VM's ARP entry in the central directory at the NVA.
	NVE asks NVA to update its mappings to record IPv4 address of VM		NVE asks NVA to update its mappings to record IPv4 address of VM
	along with MAC address of VM, and NVE IPv4 address. An NVE-to-NVA		along with MAC address of VM, and NVE IPv4 address. An NVE-to-NVA
	protocol is used for this purpose [I-D.ietf-nvo3-arch].		protocol is used for this purpose [RFC8014].
	Reverse ARP (RARP) which enables the host to discover its IPv4		Reverse ARP (RARP) which enables the host to discover its IPv4
	address when it boots from a local server [RFC0903] is not used by		address when it boots from a local server [RFC0903] is not used by
	VMs because the VM already knows its IPv4 address. IPv4/v6 address		VMs because the VM already knows its IPv4 address. IPv4/v6 address
	is assigned to a newly created VM, possibly using Dynamic Host		is assigned to a newly created VM, possibly using Dynamic Host
	Configuration Protocol (DHCP). There are some vendor deployments		Configuration Protocol (DHCP). There are some vendor deployments
	(diskless systems or systems without configuration files) wherein VM		(diskless systems or systems without configuration files) wherein VM
	users, i.e. end-user clients ask for the same MAC address upon		users, i.e. end-user clients ask for the same MAC address upon
	migration. This can be achieved by the clients sending RARP request		migration. This can be achieved by the clients sending RARP request
	reverse message which carries the old MAC address looking for an IP		reverse message which carries the old MAC address looking for an IP
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 21 ¶
	IPv6 operation is slightly different:		IPv6 operation is slightly different:
	In IPv6, the virtual machine immediately after the move sends an		In IPv6, the virtual machine immediately after the move sends an
	unsolicited neighbor advertisement message containing its IPv6		unsolicited neighbor advertisement message containing its IPv6
	address and Layer-2 MAC address in its new NVE, the destination NVE.		address and Layer-2 MAC address in its new NVE, the destination NVE.
	This message is sent to the IPv6 Solicited Node Multicast Address		This message is sent to the IPv6 Solicited Node Multicast Address
	corresponding to the target address which is VM's IPv6 address. NVE		corresponding to the target address which is VM's IPv6 address. NVE
	receives this message. NVE should update VM's neighbor cache entry		receives this message. NVE should update VM's neighbor cache entry
	in the central directory at the NVA. IPv6 address of VM, MAC address		in the central directory at the NVA. IPv6 address of VM, MAC address
	of VM and NVE IPv6 address are recorded to the entry. An NVE-to-NVA		of VM and NVE IPv6 address are recorded to the entry. An NVE-to-NVA
	protocol is used for this purpose [I-D.ietf-nvo3-arch].		protocol is used for this purpose [RFC8014].
	All NVEs communicating with this virtual machine uses the old		All NVEs communicating with this virtual machine uses the old
	neighbor cache entry. If any VM in those NVEs need to talk to the		neighbor cache entry. If any VM in those NVEs need to talk to the
	new VM in the destination NVE, it uses the old neighbor cache entry.		new VM in the destination NVE, it uses the old neighbor cache entry.
	Thus the packets are delivered to the source NVE. The source NVE		Thus the packets are delivered to the source NVE. The source NVE
	MUST tunnel these in-flight packets to the destination NVE.		MUST tunnel these in-flight packets to the destination NVE.
	When a neighbor cache entry in those VMs times out, their		When a neighbor cache entry in those VMs times out, their
	corresponding NVEs should access the NVA for an update.		corresponding NVEs should access the NVA for an update.
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 46 ¶
	accomplished seamlessly in L3 data center networks by just giving		accomplished seamlessly in L3 data center networks by just giving
	each virtual network an IP subnet and a default route that points to		each virtual network an IP subnet and a default route that points to
	NVE. This means no explosion of ARP/ neighbor cache in guests (just		NVE. This means no explosion of ARP/ neighbor cache in guests (just
	one ARP/ neighbor cache entry for default route) and we do not need		one ARP/ neighbor cache entry for default route) and we do not need
	to have Ethernet header in encapsulation [RFC7348] which saves at		to have Ethernet header in encapsulation [RFC7348] which saves at
	least 16 bytes.		least 16 bytes.
	In L3 based data center networks, since IP address of the task has to		In L3 based data center networks, since IP address of the task has to
	change after move, an IP based task migration protocol is needed.		change after move, an IP based task migration protocol is needed.
	The protocol mostly used is the identifier locator addressing or ILA		The protocol mostly used is the identifier locator addressing or ILA
	[I-D.herbert-nvo3-ila]. Address and connection migration introduce		[I-D.herbert-intarea-ila]. Address and connection migration
	complications in task migration protocol as we discuss below.		introduce complications in task migration protocol as we discuss
	Especially informing the communicating hosts of the migration becomes		below. Especially informing the communicating hosts of the migration
	a major issue. Also, in L3 based networks, because broadcasting is		becomes a major issue. Also, in L3 based networks, because
	not available, multicast of neighbor solicitations in IPv6 would need		broadcasting is not available, multicast of neighbor solicitations in
	to be emulated.		IPv6 would need to be emulated.
	Task migration involves the following steps:		Task migration involves the following steps:
	Stop running the task.		Stop running the task.
	Package the runtime state of the job.		Package the runtime state of the job.
	Send the runtime state of the task to the destination NVE where the		Send the runtime state of the task to the destination NVE where the
	task is to run.		task is to run.
	skipping to change at page 10, line 27 ¶		skipping to change at page 10, line 30 ¶
	2. Receiving an acknowledgement from the NVA regarding availability		2. Receiving an acknowledgement from the NVA regarding availability
	and usability of virtualized resources and interface package		and usability of virtualized resources and interface package
	3. Sending a confirmation message to the NVA with request for		3. Sending a confirmation message to the NVA with request for
	approval to adapt/adjust/modify the virtualized resources and		approval to adapt/adjust/modify the virtualized resources and
	interface package for utilization in a service.		interface package for utilization in a service.
	9. Security Considerations		9. Security Considerations
	Security threats for the data and control plane are discussed in		Security threats for the data and control plane are discussed in
	[I-D.ietf-nvo3-arch]. There are several issues in a multi-tenant		[RFC8014]. There are several issues in a multi-tenant environment
	environment that create problems. In L2 based data center networks,		that create problems. In L2 based data center networks, lack of
	lack of security in VXLAN, corruption of VNI can lead to delivery to		security in VXLAN, corruption of VNI can lead to delivery to wrong
	wrong tenant. Also, ARP in IPv4 and ND in IPv6 are not secure		tenant. Also, ARP in IPv4 and ND in IPv6 are not secure especially
	especially if we accept gratuitous versions. When these are done		if we accept gratuitous versions. When these are done over a UDP
	over a UDP encapsulation, like VXLAN, the problem is worse since it		encapsulation, like VXLAN, the problem is worse since it is trivial
	is trivial for a non trusted application to spoof UDP packets.		for a non trusted application to spoof UDP packets.
	In L3 based data center networks, the problem of address spoofing may		In L3 based data center networks, the problem of address spoofing may
	arise. As a result the destinations may contain untrusted hosts.		arise. As a result the destinations may contain untrusted hosts.
	This usually happens in cases like the virtual machines running third		This usually happens in cases like the virtual machines running third
	part applications. This requires the usage of stronger security		part applications. This requires the usage of stronger security
	mechanisms.		mechanisms.
	10. IANA Considerations		10. IANA Considerations
	This document makes no request to IANA.		This document makes no request to IANA.
	11. Acknowledgements		11. Acknowledgements
	The authors are grateful to Qiang Zu, Andrew Malis for helpful		The authors are grateful to Dave R. Worley, Qiang Zu, Andrew Malis
	comments.		for helpful comments.
	12. Change Log		12. Change Log
	o submitted version -00 as a working group draft after adoption		o submitted version -00 as a working group draft after adoption
			o submitted version -01 with these changes: references are updated,
			added packets in flight definition to Section 2
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-nvo3-arch]
	Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
	Narten, "An Architecture for Data Center Network
	Virtualization Overlays (NVO3)", draft-ietf-nvo3-arch-08
	(work in progress), September 2016.
	[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or		[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
	Converting Network Protocol Addresses to 48.bit Ethernet		Converting Network Protocol Addresses to 48.bit Ethernet
	Address for Transmission on Ethernet Hardware", STD 37,		Address for Transmission on Ethernet Hardware", STD 37,
	RFC 826, DOI 10.17487/RFC0826, November 1982,		RFC 826, DOI 10.17487/RFC0826, November 1982,
	<http://www.rfc-editor.org/info/rfc826>.		<https://www.rfc-editor.org/info/rfc826>.
	[RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A		[RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
	Reverse Address Resolution Protocol", STD 38, RFC 903,		Reverse Address Resolution Protocol", STD 38, RFC 903,
	DOI 10.17487/RFC0903, June 1984,		DOI 10.17487/RFC0903, June 1984,
	<http://www.rfc-editor.org/info/rfc903>.		<https://www.rfc-editor.org/info/rfc903>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,		[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
	DOI 10.17487/RFC2629, June 1999,		DOI 10.17487/RFC2629, June 1999,
	<http://www.rfc-editor.org/info/rfc2629>.		<https://www.rfc-editor.org/info/rfc2629>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<http://www.rfc-editor.org/info/rfc4861>.		<https://www.rfc-editor.org/info/rfc4861>.
	[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,		[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
	L., Sridhar, T., Bursell, M., and C. Wright, "Virtual		L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
	eXtensible Local Area Network (VXLAN): A Framework for		eXtensible Local Area Network (VXLAN): A Framework for
	Overlaying Virtualized Layer 2 Networks over Layer 3		Overlaying Virtualized Layer 2 Networks over Layer 3
	Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,		Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
	<http://www.rfc-editor.org/info/rfc7348>.		<https://www.rfc-editor.org/info/rfc7348>.
	[RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,		[RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,
	Kreeger, L., and M. Napierala, "Problem Statement:		Kreeger, L., and M. Napierala, "Problem Statement:
	Overlays for Network Virtualization", RFC 7364,		Overlays for Network Virtualization", RFC 7364,
	DOI 10.17487/RFC7364, October 2014,		DOI 10.17487/RFC7364, October 2014,
	<http://www.rfc-editor.org/info/rfc7364>.		<https://www.rfc-editor.org/info/rfc7364>.
			[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
			Narten, "An Architecture for Data-Center Network
			Virtualization over Layer 3 (NVO3)", RFC 8014,
			DOI 10.17487/RFC8014, December 2016,
			<https://www.rfc-editor.org/info/rfc8014>.
	13.2. Informative references		13.2. Informative references
	[I-D.herbert-nvo3-ila]		[I-D.herbert-intarea-ila]
	Herbert, T. and P. Lapukhov, "Identifier-locator		Herbert, T. and P. Lapukhov, "Identifier-locator
	addressing for IPv6", draft-herbert-nvo3-ila-04 (work in		addressing for IPv6", draft-herbert-intarea-ila-00 (work
	progress), March 2017.		in progress), October 2017.
	[I-D.ietf-nvo3-nve-nva-cp-req]
	Kreeger, L., Dutt, D., Narten, T., and D. Black, "Network
	Virtualization NVE to NVA Control Protocol Requirements",
	draft-ietf-nvo3-nve-nva-cp-req-05 (work in progress),
	March 2016.
	Authors' Addresses		Authors' Addresses
	Behcet Sarikaya		Behcet Sarikaya
	Huawei USA
	5340 Legacy Dr. Building 3
	Plano, TX 75024
	Email: sarikaya@ieee.org		Email: sarikaya@ieee.org
	Linda Dunbar		Linda Dunbar
	Huawei USA		Huawei USA
	5340 Legacy Dr. Building 3		5340 Legacy Dr. Building 3
	Plano, TX 75024		Plano, TX 75024
	Email: linda.dunbar@huawei.com		Email: linda.dunbar@huawei.com
End of changes. 26 change blocks.
	56 lines changed or deleted		54 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/