< draft-ietf-6lo-nfc-05.txt		draft-ietf-6lo-nfc-06.txt >
	6Lo Working Group Y-H. Choi		6Lo Working Group Y-H. Choi
	Internet-Draft Y-G. Hong		Internet-Draft Y-G. Hong
	Intended status: Standards Track ETRI		Intended status: Standards Track ETRI
	Expires: April 14, 2017 J-S. Youn		Expires: September 8, 2017 J-S. Youn
	Dongeui Univ		Dongeui Univ
	D-K. Kim		D-K. Kim
	KNU		KNU
	J-H. Choi		J-H. Choi
	Samsung Electronics Co.,		Samsung Electronics Co.,
	October 11, 2016		March 7, 2017
	Transmission of IPv6 Packets over Near Field Communication		Transmission of IPv6 Packets over Near Field Communication
	draft-ietf-6lo-nfc-05		draft-ietf-6lo-nfc-06
	Abstract		Abstract
	Near field communication (NFC) is a set of standards for smartphones		Near field communication (NFC) is a set of standards for smartphones
	and portable devices to establish radio communication with each other		and portable devices to establish radio communication with each other
	by touching them together or bringing them into proximity, usually no		by touching them together or bringing them into proximity, usually no
	more than 10 cm. NFC standards cover communications protocols and		more than 10 cm. NFC standards cover communications protocols and
	data exchange formats, and are based on existing radio-frequency		data exchange formats, and are based on existing radio-frequency
	identification (RFID) standards including ISO/IEC 14443 and FeliCa.		identification (RFID) standards including ISO/IEC 14443 and FeliCa.
	The standards include ISO/IEC 18092 and those defined by the NFC		The standards include ISO/IEC 18092 and those defined by the NFC
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 http://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 April 14, 2017.		This Internet-Draft will expire on September 8, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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		(http://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
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	3.1. Peer-to-peer Mode of NFC . . . . . . . . . . . . . . . . 4		3.1. Peer-to-peer Mode of NFC . . . . . . . . . . . . . . . . 4
	3.2. Protocol Stacks of NFC . . . . . . . . . . . . . . . . . 4		3.2. Protocol Stacks of NFC . . . . . . . . . . . . . . . . . 4
	3.3. NFC-enabled Device Addressing . . . . . . . . . . . . . . 6		3.3. NFC-enabled Device Addressing . . . . . . . . . . . . . . 6
	3.4. NFC MAC PDU Size and MTU . . . . . . . . . . . . . . . . 6		3.4. NFC MAC PDU Size and MTU . . . . . . . . . . . . . . . . 6
	4. Specification of IPv6 over NFC . . . . . . . . . . . . . . . 7		4. Specification of IPv6 over NFC . . . . . . . . . . . . . . . 7
	4.1. Protocol Stacks . . . . . . . . . . . . . . . . . . . . . 7		4.1. Protocol Stacks . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Stateless Address Autoconfiguration . . . . . . . . . . . 8		4.3. Stateless Address Autoconfiguration . . . . . . . . . . . 8
	4.4. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9		4.4. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9
	4.5. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 9		4.5. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 9
	4.6. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 9		4.6. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 10
	4.7. Header Compression . . . . . . . . . . . . . . . . . . . 10		4.7. Header Compression . . . . . . . . . . . . . . . . . . . 10
	4.8. Fragmentation and Reassembly . . . . . . . . . . . . . . 11		4.8. Fragmentation and Reassembly . . . . . . . . . . . . . . 11
	4.9. Unicast Address Mapping . . . . . . . . . . . . . . . . . 11		4.9. Unicast Address Mapping . . . . . . . . . . . . . . . . . 11
	4.10. Multicast Address Mapping . . . . . . . . . . . . . . . . 12		4.10. Multicast Address Mapping . . . . . . . . . . . . . . . . 12
	5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 12		5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 12
	5.1. NFC-enabled Device Connected to the Internet . . . . . . 12		5.1. NFC-enabled Device Connected to the Internet . . . . . . 12
	5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 13		5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	NFC is a set of short-range wireless technologies, typically		NFC is a set of short-range wireless technologies, typically
	requiring a distance of 10 cm or less. NFC operates at 13.56 MHz on		requiring a distance of 10 cm or less. NFC operates at 13.56 MHz on
	ISO/IEC 18000-3 air interface and at rates ranging from 106 kbit/s to		ISO/IEC 18000-3 air interface and at rates ranging from 106 kbit/s to
	424 kbit/s. NFC always involves an initiator and a target; the		424 kbit/s. NFC always involves an initiator and a target; the
	initiator actively generates an RF field that can power a passive		initiator actively generates an RF field that can power a passive
	target. This enables NFC targets to take very simple form factors		target. This enables NFC targets to take very simple form factors
	such as tags, stickers, key fobs, or cards that do not require		such as tags, stickers, key fobs, or cards that do not require
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 36 ¶
	because each data link connection is uniquely identified by the pair		because each data link connection is uniquely identified by the pair
	of DSAP and SSAP included in the header of each LLC PDU in NFC.		of DSAP and SSAP included in the header of each LLC PDU in NFC.
	Following the guidance of RFC 7136 [10], interface identifiers of all		Following the guidance of RFC 7136 [10], interface identifiers of all
	unicast addresses for NFC-enabled devices are 64 bits long and		unicast addresses for NFC-enabled devices are 64 bits long and
	constructed in a modified EUI-64 format as shown in Figure 3.		constructed in a modified EUI-64 format as shown in Figure 3.
	0 1 3 4 6		0 1 3 4 6
	0 6 2 8 3		0 6 2 8 3
	+----------------+----------------+----------------+-----------------+		+----------------+----------------+----------------+-----------------+
	|000000u000000000|0000000011111111|11111110RRRRRRRR|RRRRRRRRRRRRRRRRR|		|RRRRRRuRRRRRRRRR|RRRRRRRR11111111|11111110RRRRRRRR|RRRRRRRRRRRRRRRRR|
	+----------------+----------------+----------------+-----------------+		+----------------+----------------+----------------+-----------------+
	Figure 3: Formation of IID from NFC-enabled device address		Figure 3: Formation of IID from NFC-enabled device address
	The 'R' bits are random values which MAY be created by mechanisms		The 'R' bits are output values which MAY be created by mechanisms
	like hash function with the SSAP as an input value because the 6-bit		like hash functions with input values, i.e., the SSAP and other
	address of SSAP is easy and short to be targeted by attacks of third		values (e.g., prefix) because the 6-bit address of SSAP is easy and
	party (e.g., address scanning). In addition, the "Universal/Local"		short to be targeted by attacks of third party (e.g., address
	bit (i.e., the 'u' bit) of an NFC-enabled device address MUST be set		scanning). Figure 4 shows an example for IID creation. The F()
	to 0 RFC 4291 [7].		means a mechanism to make a output value for 64-bit IID, and an
			parameter, "offset" is an example input value for making the
			different output values.
			IID = F( SHA-256(6-bit SSAP, 64-bit Prefix), 'u' bit, offset )
			Figure 4: An example of an IID creation mechanism
			In addition, the "Universal/Local" bit (i.e., the 'u' bit) of an NFC-
			enabled device address MUST be set to 0 RFC 4291 [7].
	4.4. IPv6 Link Local Address		4.4. IPv6 Link Local Address
	Only if the NFC-enabled device address is known to be a public		Only if the NFC-enabled device address is known to be a public
	address, the "Universal/Local" bit be set to 1. The IPv6 link-local		address, the "Universal/Local" bit be set to 1. The IPv6 link-local
	address for an NFC-enabled device is formed by appending the IID, to		address for an NFC-enabled device is formed by appending the IID, to
	the prefix FE80::/64, as depicted in Figure 4.		the prefix FE80::/64, as depicted in Figure 5.
	0 0 0 1		0 0 0 1
	0 1 6 2		0 1 6 2
	0 0 4 7		0 0 4 7
	+----------+------------------+----------------------------+		+----------+------------------+----------------------------+
	|1111111010| zeros | Interface Identifier |		|1111111010| zeros | Interface Identifier |
	+----------+------------------+----------------------------+		+----------+------------------+----------------------------+
	| |		| |
	| <---------------------- 128 bits ----------------------> |		| <---------------------- 128 bits ----------------------> |
	| |		| |
	Figure 4: IPv6 link-local address in NFC		Figure 5: IPv6 link-local address in NFC
	The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC		The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC
	network is can be accomplished via DHCPv6 Prefix Delegation (RFC 3633		network is can be accomplished via DHCPv6 Prefix Delegation (RFC 3633
	[8]).		[8]).
	4.5. Neighbor Discovery		4.5. Neighbor Discovery
	Neighbor Discovery Optimization for 6LoWPANs (RFC 6775 [4]) describes		Neighbor Discovery Optimization for 6LoWPANs (RFC 6775 [4]) describes
	the neighbor discovery approach in several 6LoWPAN topologies, such		the neighbor discovery approach in several 6LoWPAN topologies, such
	as mesh topology. NFC does not support a complicated mesh topology		as mesh topology. NFC does not support a complicated mesh topology
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 15 ¶
	2. For sending Router Solicitations and processing Router		2. For sending Router Solicitations and processing Router
	Advertisements the NFC 6LNs MUST follow Sections 5.3 and 5.4 of		Advertisements the NFC 6LNs MUST follow Sections 5.3 and 5.4 of
	RFC 6775.		RFC 6775.
	4.6. Dispatch Header		4.6. Dispatch Header
	All IPv6-over-NFC encapsulated datagrams are prefixed by an		All IPv6-over-NFC encapsulated datagrams are prefixed by an
	encapsulation header stack consisting of a Dispatch value followed by		encapsulation header stack consisting of a Dispatch value followed by
	zero or more header fields. The only sequence currently defined for		zero or more header fields. The only sequence currently defined for
	IPv6-over-NFC is the LOWPAN_IPHC header followed by payload, as		IPv6-over-NFC is the LOWPAN_IPHC header followed by payload, as
	depicted in Figure 5.		depicted in Figure 6.
	+---------------+---------------+--------------+		+---------------+---------------+--------------+
	| IPHC Dispatch | IPHC Header | Payload |		| IPHC Dispatch | IPHC Header | Payload |
	+---------------+---------------+--------------+		+---------------+---------------+--------------+
	Figure 5: A IPv6-over-NFC Encapsulated 6LOWPAN_IPHC Compressed IPv6		Figure 6: A IPv6-over-NFC Encapsulated 6LOWPAN_IPHC Compressed IPv6
	Datagram		Datagram
	The dispatch value may be treated as an unstructured namespace. Only		The dispatch value may be treated as an unstructured namespace. Only
	a single pattern is used to represent current IPv6-over-NFC		a single pattern is used to represent current IPv6-over-NFC
	functionality.		functionality.
	+------------+--------------------+-----------+		+------------+--------------------+-----------+
	| Pattern | Header Type | Reference |		| Pattern | Header Type | Reference |
	+------------+--------------------+-----------+		+------------+--------------------+-----------+
	| 01 1xxxxx | 6LOWPAN_IPHC | [RFC6282] |		| 01 1xxxxx | 6LOWPAN_IPHC | [RFC6282] |
	+------------+--------------------+-----------+		+------------+--------------------+-----------+
	Figure 6: Dispatch Values		Figure 7: Dispatch Values
	Other IANA-assigned 6LoWPAN Dispatch values do not apply to this		Other IANA-assigned 6LoWPAN Dispatch values do not apply to this
	specification.		specification.
	4.7. Header Compression		4.7. Header Compression
	Header compression as defined in RFC 6282 [5], which specifies the		Header compression as defined in RFC 6282 [5], which specifies the
	compression format for IPv6 datagrams on top of IEEE 802.15.4, is		compression format for IPv6 datagrams on top of IEEE 802.15.4, is
	REQUIRED in this document as the basis for IPv6 header compression on		REQUIRED in this document as the basis for IPv6 header compression on
	top of NFC. All headers MUST be compressed according to RFC 6282		top of NFC. All headers MUST be compressed according to RFC 6282
	encoding formats.		encoding formats.
	Therefore, IPv6 header compression in RFC 6282 [5] MUST be		Therefore, IPv6 header compression in RFC 6282 [5] MUST be
	implemented. Further, implementations MAY also support Generic		implemented. Further, implementations MAY also support Generic
	Header Compression (GHC) of RFC 7400 [11].		Header Compression (GHC) of RFC 7400 [11].
	If a 16-bit address is required as a short address, it MUST be formed		If a 16-bit address is required as a short address, it MUST be formed
	by padding the 6-bit NFC link-layer (node) address to the left with		by padding the 6-bit NFC link-layer (node) address to the left with
	zeros as shown in Figure 7.		zeros as shown in Figure 8.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Padding(all zeros)| NFC Addr. |		| Padding(all zeros)| NFC Addr. |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: NFC short address format		Figure 8: NFC short address format
	4.8. Fragmentation and Reassembly		4.8. Fragmentation and Reassembly
	NFC provides fragmentation and reassembly (FAR) for payloads from 128		NFC provides fragmentation and reassembly (FAR) for payloads from 128
	bytes up to 2176 bytes as mentioned in Section 3.4. The MTU of a		bytes up to 2176 bytes as mentioned in Section 3.4. The MTU of a
	general IPv6 packet can fit into a single NFC link frame. Therefore,		general IPv6 packet can fit into a single NFC link frame. Therefore,
	the FAR functionality as defined in RFC 4944, which specifies the		the FAR functionality as defined in RFC 4944, which specifies the
	fragmentation methods for IPv6 datagrams on top of IEEE 802.15.4, MAY		fragmentation methods for IPv6 datagrams on top of IEEE 802.15.4, MAY
	NOT be required as the basis for IPv6 datagram FAR on top of NFC.		NOT be required as the basis for IPv6 datagram FAR on top of NFC.
	The NFC link connection for IPv6 over NFC MUST be configured with an		The NFC link connection for IPv6 over NFC MUST be configured with an
	skipping to change at page 11, line 40 ¶		skipping to change at page 11, line 52 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length=1 |		| Type | Length=1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+- Padding (all zeros) -+		+- Padding (all zeros) -+
	| |		| |
	+- +-+-+-+-+-+-+		+- +-+-+-+-+-+-+
	| | NFC Addr. |		| | NFC Addr. |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 8: Unicast address mapping		Figure 9: Unicast address mapping
	Option fields:		Option fields:
	Type:		Type:
	1: for Source Link-layer address.		1: for Source Link-layer address.
	2: for Target Link-layer address.		2: for Target Link-layer address.
	Length:		Length:
	skipping to change at page 12, line 29 ¶		skipping to change at page 12, line 39 ¶
	padding on the left with a zero. In addition, the NFC Destination		padding on the left with a zero. In addition, the NFC Destination
	Address, 0x3F, MUST NOT be used as a unicast NFC address of SSAP or		Address, 0x3F, MUST NOT be used as a unicast NFC address of SSAP or
	DSAP.		DSAP.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Padding(all zeros)|1 1 1 1 1 1|		| Padding(all zeros)|1 1 1 1 1 1|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 9: Multicast address mapping		Figure 10: Multicast address mapping
	5. Internet Connectivity Scenarios		5. Internet Connectivity Scenarios
	As two typical scenarios, the NFC network can be isolated and		As two typical scenarios, the NFC network can be isolated and
	connected to the Internet.		connected to the Internet.
	5.1. NFC-enabled Device Connected to the Internet		5.1. NFC-enabled Device Connected to the Internet
	One of the key applications of using IPv6 over NFC is securely		One of the key applications of using IPv6 over NFC is securely
	transmitting IPv6 packets because the RF distance between 6LN and		transmitting IPv6 packets because the RF distance between 6LN and
	6LBR is typically within 10 cm. If any third party wants to hack		6LBR is typically within 10 cm. If any third party wants to hack
	into the RF between them, it must come to nearly touch them.		into the RF between them, it must come to nearly touch them.
	Applications can choose which kinds of air interfaces (e.g., BT-LE,		Applications can choose which kinds of air interfaces (e.g., BT-LE,
	Wi-Fi, NFC, etc.) to send data depending on the characteristics of		Wi-Fi, NFC, etc.) to send data depending on the characteristics of
	the data.		the data.
	Figure 10 illustrates an example of an NFC-enabled device network		Figure 11 illustrates an example of an NFC-enabled device network
	connected to the Internet. The distance between 6LN and 6LBR is		connected to the Internet. The distance between 6LN and 6LBR is
	typically 10 cm or less. If there is any laptop computers close to a		typically 10 cm or less. If there is any laptop computers close to a
	user, it will become the a 6LBR. Additionally, when the user mounts		user, it will become the a 6LBR. Additionally, when the user mounts
	an NFC-enabled air interface adapter (e.g., portable NFC dongle) on		an NFC-enabled air interface adapter (e.g., portable NFC dongle) on
	the close laptop PC, the user's NFC-enabled device (6LN) can		the close laptop PC, the user's NFC-enabled device (6LN) can
	communicate with the laptop PC (6LBR) within 10 cm distance.		communicate with the laptop PC (6LBR) within 10 cm distance.
	************		************
	6LN ------------------- 6LBR -----* Internet *------- CN		6LN ------------------- 6LBR -----* Internet *------- CN
	| (dis. 10 cm or less) | ************ |		| (dis. 10 cm or less) | ************ |
	| | |		| | |
	| <-------- NFC -------> | <----- IPv6 packet ------> |		| <-------- NFC -------> | <----- IPv6 packet ------> |
	| (IPv6 over NFC packet) | |		| (IPv6 over NFC packet) | |
	Figure 10: NFC-enabled device network connected to the Internet		Figure 11: NFC-enabled device network connected to the Internet
	5.2. Isolated NFC-enabled Device Network		5.2. Isolated NFC-enabled Device Network
	In some scenarios, the NFC-enabled device network may transiently be		In some scenarios, the NFC-enabled device network may transiently be
	a simple isolated network as shown in the Figure 11.		a simple isolated network as shown in the Figure 12.
	6LN ---------------------- 6LR ---------------------- 6LN		6LN ---------------------- 6LR ---------------------- 6LN
	| (10 cm or less) | (10 cm or less) |		| (10 cm or less) | (10 cm or less) |
	| | |		| | |
	| <--------- NFC --------> | <--------- NFC --------> |		| <--------- NFC --------> | <--------- NFC --------> |
	| (IPv6 over NFC packet) | (IPv6 over NFC packet) |		| (IPv6 over NFC packet) | (IPv6 over NFC packet) |
	Figure 11: Isolated NFC-enabled device network		Figure 12: Isolated NFC-enabled device network
	In mobile phone markets, applications are designed and made by user		In mobile phone markets, applications are designed and made by user
	developers. They may image interesting applications, where three or		developers. They may image interesting applications, where three or
	more mobile phones touch or attach each other to accomplish		more mobile phones touch or attach each other to accomplish
	outstanding performance.		outstanding performance.
	6. IANA Considerations		6. IANA Considerations
	There are no IANA considerations related to this document.		There are no IANA considerations related to this document.
End of changes. 22 change blocks.
	27 lines changed or deleted		36 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/