< draft-smith-ietf-routers-vs-hosts-00.txt		draft-smith-ietf-routers-vs-hosts-01.txt >
	Internet Engineering Task Force M.R. Smith		Internet Engineering Task Force M.R. Smith
	Internet-Draft 3 May 2022		Internet-Draft 5 May 2022
	Intended status: Informational		Intended status: Informational
	Expires: 4 November 2022		Expires: 6 November 2022
	Routers Verses Hosts; Devices Verses Functions		Routers Verses Hosts; Devices Verses Functions
	draft-smith-ietf-routers-vs-hosts-00		draft-smith-ietf-routers-vs-hosts-01
	Abstract		Abstract
	This memo discusses the differences between routers verses hosts, as		This memo discusses the differences between routers verses hosts, as
	devices verses functions. It then discusses Internet Protocol		devices verses functions. It then discusses Internet Protocol
	architectural considerations and consequences based on these		architectural considerations and consequences based on these
	differences and definitions.		differences and definitions.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 https://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 4 November 2022.		This Internet-Draft will expire on 6 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Routers and Hosts Model . . . . . . . . . . . . . . . . . . . 3		2. Routers verses Hosts . . . . . . . . . . . . . . . . . . . . 3
	2.1. Routers verses Hosts . . . . . . . . . . . . . . . . . . 3		2.1. Router verses Host Functions . . . . . . . . . . . . . . 3
	2.1.1. Routing Function Goal . . . . . . . . . . . . . . . . 3		2.1.1. Routing Function Goal . . . . . . . . . . . . . . . . 3
	2.1.2. Only Hosts Hold IPv6 Addresses . . . . . . . . . . . 4		2.1.2. Only Hosts Hold IPv6 Addresses . . . . . . . . . . . 4
	2.1.3. Host Function Goal . . . . . . . . . . . . . . . . . 4		2.1.3. Host Function Goal . . . . . . . . . . . . . . . . . 4
	2.1.4. Demarcation Point . . . . . . . . . . . . . . . . . . 5		2.1.4. Demarcation Point . . . . . . . . . . . . . . . . . . 5
	2.1.5. The Physical Postal System . . . . . . . . . . . . . 5		2.1.5. The Physical Postal System . . . . . . . . . . . . . 5
	2.1.6. Dumb Network, Smart Hosts . . . . . . . . . . . . . . 6		2.1.6. Dumb Network, Smart Hosts . . . . . . . . . . . . . . 7
	2.1.7. Hop by Hop "Network" Processing . . . . . . . . . . . 7		2.1.7. Hop by Hop "Network" Processing . . . . . . . . . . . 7
	2.1.8. An Example - The Routing Header . . . . . . . . . . . 8		2.1.8. An Example - The Routing Header . . . . . . . . . . . 8
	2.1.9. A Counter Example - The Hop By Hop Options Header . . 8		2.1.9. A Counter Example - The Hop By Hop Options Header . . 8
	2.1.10. Theory Verses Practice - Routers and Hosts As Physical		2.1.10. Theory Verses Practice - Routers and Hosts As Physical
	Devices . . . . . . . . . . . . . . . . . . . . . . . 8		Devices . . . . . . . . . . . . . . . . . . . . . . . 9
	2.1.10.1. Router Devices . . . . . . . . . . . . . . . . . 9		2.1.10.1. Router Devices . . . . . . . . . . . . . . . . . 9
	2.1.10.2. Host Devices . . . . . . . . . . . . . . . . . . 10		2.1.10.2. Host Devices . . . . . . . . . . . . . . . . . . 10
	2.1.10.3. Fast Path verses Slow Path . . . . . . . . . . . 10		2.1.10.3. Fast Path verses Slow Path . . . . . . . . . . . 10
	2.2. Contrary Examples . . . . . . . . . . . . . . . . . . . . 10		2.2. Contrary Examples . . . . . . . . . . . . . . . . . . . . 10
	2.2.1. BGP Route Servers and Route Reflectors . . . . . . . 10		2.2.1. BGP Route Servers and Route Reflectors . . . . . . . 10
	2.2.2. Commodity PCs as Routers . . . . . . . . . . . . . . 11		2.2.2. Commodity PCs as Routers . . . . . . . . . . . . . . 11
	2.3. All IPv6 Addresses are Host Addresses . . . . . . . . . . 11		2.3. Routers holding IPv6 Addresses . . . . . . . . . . . . . 11
	2.4. Forwarding verses Non-Forwarding Interfaces . . . . . . . 11		2.4. Forwarding verses Non-Forwarding Interfaces . . . . . . . 11
	3. HBH Function Encoding . . . . . . . . . . . . . . . . . . . . 12		3. HBH Function Encoding . . . . . . . . . . . . . . . . . . . . 11
	4. Additional HBH Information . . . . . . . . . . . . . . . . . 12		4. Additional HBH Information . . . . . . . . . . . . . . . . . 12
	5. Host Requested . . . . . . . . . . . . . . . . . . . . . . . 12		5. Host Requested . . . . . . . . . . . . . . . . . . . . . . . 12
	6. Network Imposed . . . . . . . . . . . . . . . . . . . . . . . 12		6. Network Imposed . . . . . . . . . . . . . . . . . . . . . . . 12
	7. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	11. Change Log [RFC Editor please remove] . . . . . . . . . . . . 12		11. Change Log [RFC Editor please remove] . . . . . . . . . . . . 12
	12. Informative References . . . . . . . . . . . . . . . . . . . 12		12. Informative References . . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	This memo discusses the differences between routers verses hosts, as		This memo discusses the differences between routers verses hosts, as
	devices verses functions. It then discusses Internet Protocol		devices verses functions. It then discusses Internet Protocol
	architectural considerations and consequences based on these		architectural considerations and consequences based on these
	differences and definitions.		differences and definitions.
	2. Routers and Hosts Model		2. Routers verses Hosts
	2.1. Routers verses Hosts		2.1. Router verses Host Functions
	[RFC8200] defines a node, and two types of IPv6 nodes:		[RFC8200] defines an IPv6 node, and two types of IPv6 nodes:
	node - "a device that implements IPv6."		node - "a device that implements IPv6."
	router - "a node that forwards IPv6 packets not explicitly addressed		router - "a node that forwards IPv6 packets not explicitly
	to itself.		addressed to itself."
	host - "any node that is not a router."		host - "any node that is not a router."
	Although "node" is described as a device, and most people will think		Although "node" is described as a device, and most people will think
	of a "device" as a physical, well, device, "host" and "router" are		of a "device" as a physical, well, device, "host" and "router" are
	really functional definitions, indicating the goal and type of		really functional definitions, indicating the goal and type of
	processing that is to be performed on the IPv6 packet by the node.		processing that is to be performed on the IPv6 packet by the node.
	Stephen Deering, one of the co-designers of IPv6 [RFC8200], has		Stephen Deering, one of the co-designers of IPv6 [RFC8200], has
	described routers in functional terms in other RFCs. For example, in		described routers in functional terms in other RFCs. For example, in
	[RFC1075], a "router" is described as:		[RFC1075], a "router" is described as:
	* The process or processes that perform the routing and forwarding		The process or processes that perform the routing and forwarding
	functions are called "routers" in this memo.		functions are called "routers" in this memo.
	Or, in [RFC1256] (the likely origin of IPv6 Router Advertisements), a		Or, in [RFC1256] (the likely origin of IPv6 Router Advertisements), a
	router is defined as:		router is defined as:
	* a system that forwards IP datagrams		a system that forwards IP datagrams
	The definition of the word "device" doesn't actually require a device		The definition of the word "device" doesn't actually require a device
	to be physical [DICTIONARY REF, VW DEFEAT DEVICE].		to be physical [DICTIONARY REF, VW DEFEAT DEVICE].
			In this memo we will consider routers and hosts as functions before
			considering routers and hosts as physical devices.
	2.1.1. Routing Function Goal		2.1.1. Routing Function Goal
	As per the [RFC8200] definition, the goal of the routing function is		As per the [RFC8200] definition, the goal of the routing function is
	to forward an IPv6 packet towards an IPv6 node that explicitly holds		to forward an IPv6 packet towards an IPv6 node that explicitly holds
	the packet's destination address. This forwarding function is		the packet's destination address. This forwarding function is
	limited to the fixed portion of the IPv6 header, so that it can be		limited to the fixed portion of the IPv6 header, so that it can be
	performed as simply, and therefore as fast as possible. Simpler		performed as simply, and therefore as fast as possible. Simpler
	operations on a packet can better facilitate faster and cheaper		operations on a packet can better facilitate faster and cheaper
	implementations, both in software and in fixed or limited function		implementations, both in software and in fixed or limited function
	hardware.		hardware.
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 37 ¶
	exist without it.		exist without it.
	2.1.2. Only Hosts Hold IPv6 Addresses		2.1.2. Only Hosts Hold IPv6 Addresses
	If the goal of the routing function is to forward packets "not		If the goal of the routing function is to forward packets "not
	explicitly addressed to itself", and a host is "any node that is not		explicitly addressed to itself", and a host is "any node that is not
	a router", then it means that all IPv6 nodes that hold IPv6 addresses		a router", then it means that all IPv6 nodes that hold IPv6 addresses
	are hosts.		are hosts.
	Or rather, IPv6 addresses are only assigned to hosts. IPv6 addresses		Or rather, IPv6 addresses are only assigned to hosts. IPv6 addresses
	are host addresses.		are always host addresses.
	Remember, this is the definition of a host function, not a host		This also means only hosts originate packets, and only hosts receive
	"device", and also remember that a "device" isn't actually required		packets. Routers only forward packets.
	to be a physical thing.
	Routers as physical devices (and hosts as physical devices) are		Remember, these host and router definitions are functional, not
	discussed later.		router or host physical "device" definitions, and also remember that
			a "device" isn't actually required to be a physical thing.
			Routers and hosts as physical devices are discussed later.
	2.1.3. Host Function Goal		2.1.3. Host Function Goal
	The goal of the host function is to process the IPv6 packet in depth,		The goal of the host function is to process the IPv6 packet in depth,
	beyond the IPv6 fixed header, when the packet arrives at the host		beyond the IPv6 fixed header, when the packet arrives at the host
	holding the destination address specified in the packet.		holding the destination address specified in the packet.
	The type of processing to be performed is specified by the IPv6		The type of processing to be performed is specified by the IPv6
	packet's fixed header next header field, optional Extension Headers,		packet's fixed header next header field, optional Extension Headers,
	and then subsequent transport layer header (an Extension Header too,		and then subsequent transport layer header (an Extension Header too,
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 18 ¶
	package or packet from the source address to the destination address		package or packet from the source address to the destination address
	on the outside of the container.		on the outside of the container.
	The postal system is transparent to the contents of the envelope,		The postal system is transparent to the contents of the envelope,
	package or packets it is asked to deliver. Whether a envelope		package or packets it is asked to deliver. Whether a envelope
	carries a large value financial check (cheque), or a package is		carries a large value financial check (cheque), or a package is
	carrying 1 kilogram of gold is not visible to the postal system.		carrying 1 kilogram of gold is not visible to the postal system.
	Delivery occurs regardless, usually dependent on weight. Lead or		Delivery occurs regardless, usually dependent on weight. Lead or
	gold costs the same to transport.		gold costs the same to transport.
			Once the envelope, package or packet arrives at the specified
			destination address, it is then open and its contents (payload) are
			"processed" by the receiver identified by the destination address.
	Payload encryption isn't commonly used to ensure that envelopes and		Payload encryption isn't commonly used to ensure that envelopes and
	packages are opened "mid-flight", preserving payload transparency.		packages are opened "mid-flight", preserving payload transparency.
	However, this transparency is instead enforced by very strong laws		However, this transparency is instead enforced by very strong laws
	with harsh pentalities against unauthorised opening of envelopes and		with harsh pentalities against unauthorised opening of envelopes and
	packets (e.g. in Australia, the penalty is 2 to 5 years in jail		packets (e.g. in Australia, the penalty is 2 to 5 years in jail
	[REF]).		[REF]). (Postcards are an interesting case - clearly the payload is
			visible to the postal system, since they're not enclosed in an
	The Internet communications model is not new, it is really just an		enverlope. However, that's known and expected by the sender.
	electronic version of the 2500 year old postal system [REF]. What		Postcards could have their payload text encrypted by the sender.)
	processing should happen where in the Internet and, in packet
	forwarding in general, can be strongly guided by the history and
	evolution of the physical postal system.
	[IEN5] "SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM - TCP		[IEN5] "SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM - TCP
	- (Version 2)" clearly links the Internet Protocol architecture to		- (Version 2)" clearly links the Internet Protocol architecture to
	the postal system by saying that "The TCP acts in many ways like a		the postal system by saying that "The TCP acts in many ways like a
	postal service since it provides a way for processes to exchange		postal service since it provides a way for processes to exchange
	letters with each other.", and by using the term "letter" to describe		letters with each other.", and by using the term "letter" to describe
	messages between processes that are using TCP. Note that this was		messages between processes that are using TCP. Note that this was
	before the Internet Protocol was split off from TCP in [IENxx] (now		before the Internet Protocol was split off from TCP in [IENxx] (which
	known as TCP/IP), so this postal service analogy is applying to the		became known as TCP/IP), so the term "TCP" is implicitly applying to
	combination of both TCP and IP.		IP.
			The Internet communications model is not new, it is really just an
			electronic version of the 2500 year old postal system [REF]. Postal
			envelopes, packages and packets are analogs of Internet Protocol
			packets. What processing should happen where in the Internet and, in
			packet forwarding in general, can be strongly guided by the history
			and evolution of the physical postal system.
	2.1.6. Dumb Network, Smart Hosts		2.1.6. Dumb Network, Smart Hosts
	The term "Dumb network, smart hosts" [Huitema] has been used to		The term "Dumb network, smart hosts" [Huitema] has been used to
	summarise the fundamental model of the Internet protocols. Hosts do		summarise the fundamental model of the Internet protocols. Hosts do
	smart (and complex) packet processing, the network does dumb (and		smart (and complex) packet processing, the network does dumb (and
	therefore fast) packet processing (i.e., forwarding).		therefore fast) packet processing (i.e., forwarding).
	One of the very significant advantages of this model is that it has		One of the very significant advantages of this model is that it has
	allowed the Internet to better scale. Since the paths across the		allowed the Internet to better scale. Since the paths across the
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 29 ¶
	of a forwarding domain for delivery to the new next hop, now		of a forwarding domain for delivery to the new next hop, now
	identified by the packet's newly replaced destination address.		identified by the packet's newly replaced destination address.
	This hop by hop processing path across the network from the original		This hop by hop processing path across the network from the original
	packet source host to the final packet destination consists of a set		packet source host to the final packet destination consists of a set
	of separate forwarding domains, delimited by intermediate hosts.		of separate forwarding domains, delimited by intermediate hosts.
	2.1.8. An Example - The Routing Header		2.1.8. An Example - The Routing Header
	Per [RFC8200], "The Routing header is used by an IPv6 source to list		Per [RFC8200], "The Routing header is used by an IPv6 source to list
	one or more intermediate nodes to be \"visited\" on the way to a		one or more intermediate nodes to be visited on the way to a packet's
	packet's destination."		destination."
	The intermediate nodes are identified by a list of IPv6 destination		The intermediate nodes are identified by a list of IPv6 destination
	addresses. Consequently, going by the [RFC8200] router and host		addresses. Consequently, going by the [RFC8200] router and host
	definitions, a Routing Header is listing a set of hosts to visit on a		definitions, a Routing Header is listing a set of hosts to visit on a
	path towards the final host, also identified by an IPv6 destination		path towards the final host, also identified by an IPv6 destination
	address.		address.
	2.1.9. A Counter Example - The Hop By Hop Options Header		2.1.9. A Counter Example - The Hop By Hop Options Header
	The Hop-by-Hop Options Header "is used to carry optional information		The Hop-by-Hop Options Header "is used to carry optional information
	skipping to change at page 8, line 40 ¶		skipping to change at page 9, line 8 ¶
	processing involved is beyond the purpose of forwarding and		processing involved is beyond the purpose of forwarding and
	delivering the packet to the packet's destination address.		delivering the packet to the packet's destination address.
	This is host or packet payload processing beyond the fixed IPv6		This is host or packet payload processing beyond the fixed IPv6
	header. Yet it is not normally occurring at an IPv6 node, or rather		header. Yet it is not normally occurring at an IPv6 node, or rather
	host, that holds the packet's destination address.		host, that holds the packet's destination address.
	[RFC2460] required all routers to look for the Hop-by-Hop options		[RFC2460] required all routers to look for the Hop-by-Hop options
	header, and to process it if present. [RFC8200] loosened this		header, and to process it if present. [RFC8200] loosened this
	requirement because high performance IPv6 forwarding implementations		requirement because high performance IPv6 forwarding implementations
	were purely forwarding on a packet's destination address.		were purely forwarding on a packet's destination address. Router
			implementations weren't looking past the IPv6 fixed header.
	2.1.10. Theory Verses Practice - Routers and Hosts As Physical Devices		2.1.10. Theory Verses Practice - Routers and Hosts As Physical Devices
	It is common for many, if not all people in networking to imagine a		It is common for many, if not all people in networking to imagine a
	"router" or a "host" as a physical device, with physical attributes		"router" or a "host" as a physical device, with physical attributes
	that are typical of the function being performed by and that suit the		that are typical of the function being performed by and that suit the
	common use of the device.		common use of the device.
	2.1.10.1. Router Devices		2.1.10.1. Router Devices
	skipping to change at page 11, line 25 ¶		skipping to change at page 11, line 29 ¶
	A PC acting as a router can be more discreet than a whole of device		A PC acting as a router can be more discreet than a whole of device
	role. Some interfaces can be "forwarding interfaces", meaning they		role. Some interfaces can be "forwarding interfaces", meaning they
	accept packets "not explicitly addressed to itself" and attempt to		accept packets "not explicitly addressed to itself" and attempt to
	forward them.		forward them.
	Other interfaces in the PC may not accept packets "not explicitly		Other interfaces in the PC may not accept packets "not explicitly
	addressed to itself", and drop them. The interface will only accept		addressed to itself", and drop them. The interface will only accept
	packets for which host processing is to occur.		packets for which host processing is to occur.
	2.3. All IPv6 Addresses are Host Addresses		2.3. Routers holding IPv6 Addresses
	As the routing function does not originate packets, but only forwards
	them, then it means that only hosts are the originators or final
	destinations of packets that are forwarded by the network.
	As a consequence, it means that the IPv6 source and destination		If a packet source or destination address identifies a "router", it
	addresses in a packet are only host addresses. The routing or		is really identifying the host function, or control plane, that
	forwarding function does not have IPv6 addresses and never places		resides within the router as a device.
	them in a packet source or destination address field, because it
	never originates or is the final receiver of a packet. If a packet
	source or destination address identifies a "router", it is really
	identifying the host function, or control plane, that resides within
	the router as a device.
	2.4. Forwarding verses Non-Forwarding Interfaces		2.4. Forwarding verses Non-Forwarding Interfaces
	Whether or not a device is a router is more discrete than whether the		Whether or not a device is a router is more discrete than whether the
	device as a whole is nominated as a "router" or a "host".		device as a whole is nominated as a "router" or a "host".
	Whether or not to forward a received packet is property or attribute		Whether or not to forward a received packet is property or attribute
	of an IPv6 enabled interface; if the interface accepts a packet that		of an IPv6 enabled interface; if the interface accepts a packet that
	does not have a Destination Address that matches that assigned to the		does not have a Destination Address that matches that assigned to the
	interface, then the device will act as a router for that packet, by		interface, then the device will act as a router for that packet, by
	skipping to change at page 12, line 33 ¶		skipping to change at page 12, line 26 ¶
	10. Acknowledgements		10. Acknowledgements
	Review and comments were provided by YOUR NAME HERE!		Review and comments were provided by YOUR NAME HERE!
	This memo was prepared using the xml2rfc tool.		This memo was prepared using the xml2rfc tool.
	11. Change Log [RFC Editor please remove]		11. Change Log [RFC Editor please remove]
	draft-smith-ietf-routers-vs-hosts-00, initial version, 2022-05-03		draft-smith-ietf-routers-vs-hosts-00, initial version, 2022-05-03
			draft-smith-ietf-routers-vs-hosts-01, 2022-05-04
			* miscellaneous tweaks
			* postal system clarifications
			* mostly merge IPv6 addresses are host addresses sections
	12. Informative References		12. Informative References
	[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance		[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
	Vector Multicast Routing Protocol", RFC 1075,		Vector Multicast Routing Protocol", RFC 1075,
	DOI 10.17487/RFC1075, November 1988,		DOI 10.17487/RFC1075, November 1988,
	<https://www.rfc-editor.org/info/rfc1075>.		<https://www.rfc-editor.org/info/rfc1075>.
	[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages",		[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages",
	RFC 1256, DOI 10.17487/RFC1256, September 1991,		RFC 1256, DOI 10.17487/RFC1256, September 1991,
	<https://www.rfc-editor.org/info/rfc1256>.		<https://www.rfc-editor.org/info/rfc1256>.
End of changes. 29 change blocks.
	51 lines changed or deleted		64 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/