< draft-ymbk-idr-l3nd-ulpc-03.txt		draft-ymbk-idr-l3nd-ulpc-04.txt >
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft Arrcus & IIJ		Internet-Draft Arrcus & IIJ
	Intended status: Standards Track K. Patel		Intended status: Standards Track K. Patel
	Expires: 8 September 2022 Arrcus		Expires: 22 September 2022 Arrcus
	7 March 2022		21 March 2022
	L3ND Upper-Layer Protocol Configuration		L3ND Upper-Layer Protocol Configuration
	draft-ymbk-idr-l3nd-ulpc-03		draft-ymbk-idr-l3nd-ulpc-04
	Abstract		Abstract
	This document adds PDUs to the Layer-3 Neighbor Discovery protocol to		This document adds PDUs to the Layer-3 Neighbor Discovery protocol to
	communicate the parameters needed to exchange inter-device Upper		communicate the parameters needed to exchange inter-device Upper
	Layer Protocol Configuration for upper-layer protocols such as the		Layer Protocol Configuration for upper-layer protocols such as the
	BGP family.		BGP family.
	Requirements Language		Requirements Language
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 8 September 2022.		This Internet-Draft will expire on 22 September 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
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	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. Reading and Terminology . . . . . . . . . . . . . . . . . . . 2		2. Reading and Terminology . . . . . . . . . . . . . . . . . . . 2
	3. Upper-Layer Protocol Configuration PDU . . . . . . . . . . . 3		3. Upper-Layer Protocol Configuration PDU . . . . . . . . . . . 3
	3.1. ULPC BGP Attribute sub-TLVs . . . . . . . . . . . . . . . 4		3.1. ULPC BGP Attribute sub-TLVs . . . . . . . . . . . . . . . 4
	3.1.1. BGP ASN . . . . . . . . . . . . . . . . . . . . . . . 5		3.1.1. BGP ASN . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1.2. BGP IPv4 Address . . . . . . . . . . . . . . . . . . 5		3.1.2. BGP IPv4 Address . . . . . . . . . . . . . . . . . . 5
	3.1.3. BGP IPv6 Address . . . . . . . . . . . . . . . . . . 5		3.1.3. BGP IPv6 Address . . . . . . . . . . . . . . . . . . 6
	3.1.4. BGP Authentication sub-TLV . . . . . . . . . . . . . 6		3.1.4. BGP Authentication sub-TLV . . . . . . . . . . . . . 6
	3.1.5. BGP Miscellaneous Flags . . . . . . . . . . . . . . . 6		3.1.5. BGP Miscellaneous Flags . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 7		4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . 8
	7.2. Informative References . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Massive Data Centers (MDCs) which use upper-layer protocols such as		Massive Data Centers (MDCs) which use upper-layer protocols such as
	BGP4 and other routing protocols may use the Layer-3 Neighbor		BGP4 and other routing protocols may use the Layer-3 Neighbor
	Discovery Protocol, L3ND, [I-D.ymbk-idr-l3nd] to reveal the inter-		Discovery Protocol, L3ND, [I-D.ymbk-idr-l3nd] to reveal the inter-
	device links of the topology. It is desirable for devices to		device links of the topology. It is desirable for devices to
	facilitate the configuration parameters of those upper layer		facilitate the configuration parameters of those upper layer
	protocols to enable more hands-free configuration. This document		protocols to enable more hands-free configuration. This document
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 19 ¶
	on a link, a neutral sub-TLV based Upper-Layer Protocol PDU is		on a link, a neutral sub-TLV based Upper-Layer Protocol PDU is
	defined as follows:		defined as follows:
	0 1 2 3		0 1 2 3
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Version = 0 | Type = 8 | Payload Length |		| Version = 0 | Type = 8 | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | ULPC Type | AttrCount |		| | ULPC Type | AttrCount |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Serial Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Attribute List ... |		| Attribute List ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Version, Type, and Payload Length as defined in		The Version, Type, and Payload Length as defined in
	[I-D.ymbk-idr-l3nd] apply to this PDU.		[I-D.ymbk-idr-l3nd] apply to this PDU.
	The BGP Authentication sub-TLV provides for provisioning MD5, which		The BGP Authentication sub-TLV provides for provisioning MD5, which
	is a quite weak hash, horribly out of fashion, and kills puppies.		is a quite weak hash, horribly out of fashion, and kills puppies.
	But, like it or not, it has been sufficient against the kinds of		But, like it or not, it has been sufficient against the kinds of
	attacks BGP TCP sessions have endured. So it is what BGP deployments		attacks BGP TCP sessions have endured. So it is what BGP deployments
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	TLVs within an Upper-Layer Protocol PDU. The following describe the		TLVs within an Upper-Layer Protocol PDU. The following describe the
	various sub-TLVs for BGP.		various sub-TLVs for BGP.
	The goal is to provide the minimal set of configuration parameters		The goal is to provide the minimal set of configuration parameters
	needed by BGP OPEN to successfully start a BGP peering. The goal is		needed by BGP OPEN to successfully start a BGP peering. The goal is
	specifically not to replace or conflict with data exchanged during		specifically not to replace or conflict with data exchanged during
	BGP OPEN. Multiple sources of truth are a recipe for complexity and		BGP OPEN. Multiple sources of truth are a recipe for complexity and
	hence pain.		hence pain.
	If there are multiple BGP sessions on a link, e.g., IPv4 and IPv6,		If there are multiple BGP sessions on a link, e.g., IPv4 and IPv6,
	then multiple sets of BGP sub-TLVs MAY BE exchanged within the BGP		then separate BGP ULPC PDUs should be sent, one for each address
	ULPC PDU or sepatate BGP ULPC PDUs may be sent, one for each address
	family.		family.
	A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU for		A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU for
	an particular address family on a specific link at any point in time;		an particular address family on a specific link at any point in time;
	receipt of a new BGP ULPC PDU for a particular address family		receipt of a new BGP ULPC PDU for a particular address family
	replaces any previous one.		replaces the data any previous one; but does not actually affect the
			session.
	If there are one or more open BGP sessions, receipt of a new BGP ULPC		If there are one or more open BGP sessions, receipt of a new BGP ULPC
	PDU SHOULD not affect these sessions and the PDU SHOULD be discarded.		PDU SHOULD not affect these sessions. The received data are stored
	If a peer wishes to replace an open BGP session, they MUST first		for a future session restart.
	close the running BGP session and then send a new BGP ULPC PDU.
	As a link may have multiple encapsulations and multiple addresses for		As a link may have multiple encapsulations and multiple addresses for
	an IP encapsulation, which address of which encapsulation is to be		an IP encapsulation, which address of which encapsulation is to be
	used for the BGP session MUST be specified.		used for the BGP session MUST be specified.
	For each BGP peering on a link here MUST be one agreed encapsulation,		For each BGP peering on a link here MUST be one agreed encapsulation,
	and the addresses used MUST be in the corresponding L3ND IPv4/IPv6		and the addresses used MUST be in the corresponding L3ND IPv4/IPv6
	Encapsulation PDUs. If the choice is ambiguous, an Attribute may be		Encapsulation PDUs. If the choice is ambiguous, an Attribute may be
	used to signal preferences.		used to signal preferences.
	If a peering address has been announced as a loopback, i.e. MUST BE		If a peering address has been announced as a loopback, i.e. MUST BE
	flagged as such in the L3ND Encapsulation PDU (see		flagged as such in the L3ND Encapsulation PDU (see
	[I-D.ymbk-idr-l3nd] Sec. 10.2), a two or three hop BGP session MUST		[I-D.ymbk-idr-l3nd] Sec. 10.2), a two or three hop BGP session MUST
	be established. Otherwise a direct one hop session is used. The BGP		be established as needed. Otherwise a direct one hop session is
	session to a loopback will forward to the peer's address which was		used. The BGP session to a loopback will forward to the peer's
	marked as Primary in the L3ND Encapsulation Flags, iff it is in a		address which was marked as Primary in the L3ND Encapsulation Flags,
	subnet which is shared with both BGP speakers. If the primary is not		iff it is in a subnet which is shared with both BGP speakers. If the
	in a common subnet, then the BGP speaker MAY pick a forwarding next		primary is not in a common subnet, then the BGP speaker MAY pick a
	hop that is in a subnet they share. If there are multiple choices,		forwarding next hop that is in a subnet they share. If there are
	the BGP speaker SHOULD have signaled which subnet to choose in an		multiple choices, the BGP speaker SHOULD have signaled which subnet
	Upper-Layer Protocol Configuration PDU Attribute.		to choose in an Upper-Layer Protocol Configuration PDU Attribute.
	Attributes MUST be unique in the Attribute List. I.e. a particular		Attributes MUST be unique in the Attribute List. I.e. a particular
	Attr Type MUST NOT occur more than once in the Attribute List. If a		Attr Type MUST NOT occur more than once in the Attribute List. If a
	ULPC PDU is received with multiple occurances of the same Attr Type,		ULPC PDU is received with more than one occurrence of a particular
	an Error ACK should be returned.		Attr Type, an Error ACK MUST be returned.
			As there are separate PDU Attr Types for IPv4 and IPv6 peering
			addresses, separate sessions for the two AFIs MAY be created for the
			same ASN in one ULPC PDU.
	3.1.1. BGP ASN		3.1.1. BGP ASN
	The four octet Autonomous System number MUST be specified. If the AS		The four octet Autonomous System number MUST be specified. If the AS
	Number is less than 32 bits, it is padded with high order zeros.		Number is less than 32 bits, it is padded with high order zeros.
	0 1 2 3		0 1 2 3
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Attr Type = 1 | Attr Len = 6 | My ASN ~		| Attr Type = 1 | Attr Len = 4 | My ASN ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.1.2. BGP IPv4 Address		3.1.2. BGP IPv4 Address
	TheBGP IPv4 Address sub-TLV announces the sender's four octet IPv4		The BGP IPv4 Address sub-TLV announces the sender's four octet IPv4
	BGP peering source address and one octet Prefix Lenth to be used by		BGP peering source address and one octet Prefix Lenth to be used by
	the receiver. At least one of IPv4 or IPv6 BGP source addresses MUST		the receiver. At least one of IPv4 or IPv6 BGP source addresses MUST
	be announced.		be announced.
	As usual, the BGP OPEN capability negotiation will determine the AFI/		As usual, the BGP OPEN capability negotiation will determine the AFI/
	SAFIs to be transported over the peering, see [RFC4760].		SAFIs to be transported over the peering, see [RFC4760].
	0 1 2 3		0 1 2 3
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 6 ¶		skipping to change at page 6, line 13 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.1.3. BGP IPv6 Address		3.1.3. BGP IPv6 Address
	The BGP IPv6 Address sub-TLV announces the sender's 16 octet IPv6 BGP		The BGP IPv6 Address sub-TLV announces the sender's 16 octet IPv6 BGP
	peering source address and one octet Prefix Length to be used by the		peering source address and one octet Prefix Length to be used by the
	receiver. At least one of IPv4 or IPv6 BGP source addresses MUST be		receiver. At least one of IPv4 or IPv6 BGP source addresses MUST be
	announced.		announced.
	As usual, the BGP OPEN capability negotiation will determine the AFI/		As usual, the BGP OPEN capability negotiation will determine the AFI/
	SAFIs to be transported over the peering, see [RFC4760] .		SAFIs to be transported over the peering, see [RFC4760].
	0 1 2 3		0 1 2 3
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Attr Type = 3 | Attr Len = 19 | |		| Attr Type = 3 | Attr Len = 17 | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| |		| |
	+ +		+ +
	| My IPv6 Peering Address |		| My IPv6 Peering Address |
	+ +		+ +
	| |		| |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Prefix Len |		| | Prefix Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 47 ¶		skipping to change at page 7, line 8 ¶
	3.1.5. BGP Miscellaneous Flags		3.1.5. BGP Miscellaneous Flags
	The BGP session OPEN has extensive, and a bit complex, capability		The BGP session OPEN has extensive, and a bit complex, capability
	negotiation facilities. In case one or more extra attributes might		negotiation facilities. In case one or more extra attributes might
	be needed, the two octet BGP Miscellaneous Flags sub-TLV may be used.		be needed, the two octet BGP Miscellaneous Flags sub-TLV may be used.
	0 1 2 3		0 1 2 3
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Attr Type = 5 | Attr Len = 4 | Misc Flags |		| Attr Type = 5 | Attr Len = 2 | Misc Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Misc Attrs:		Misc Flags:
	Bit 0: GTSM		Bit 0: GTSM
	Bit 1-15: Must be zero		Bit 1-15: Must be zero
	The GTSM flag, when 1, indicates that the sender wishes to enable the		The GTSM flag, when 1, indicates that the sender wishes to enable the
	[RFC5082] Generalized TTL Security Mechanism for the session.		[RFC5082] Generalized TTL Security Mechanism for the session.
	4. Security Considerations		4. Security Considerations
	All the Security considerations of [I-D.ymbk-idr-l3nd] apply to this		All the Security considerations of [I-D.ymbk-idr-l3nd] apply to this
	PDU.		PDU.
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 16 ¶
	----- -------------------		----- -------------------
	0 Reserved		0 Reserved
	1 BGP		1 BGP
	2-255 Reserved		2-255 Reserved
	6. Acknowledgments		6. Acknowledgments
	The authors thank Rob Austein, Sue Hares, and Russ Housley.		The authors thank Rob Austein, Sue Hares, and Russ Housley.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ymbk-idr-l3nd]		[I-D.ymbk-idr-l3nd]
	Bush, R., Housley, R., Austein, R., Hares, S., and K.		Bush, R., Housley, R., Austein, R., Hares, S., and K.
	Patel, "Layer-3 Neighbor Discovery", Work in Progress,		Patel, "Layer-3 Neighbor Discovery", Work in Progress,
	Internet-Draft, draft-ymbk-idr-l3nd-01, 3 March 2022,		Internet-Draft, draft-ymbk-idr-l3nd-02, 7 March 2022,
	<https://www.ietf.org/archive/id/draft-ymbk-idr-l3nd-		<https://www.ietf.org/archive/id/draft-ymbk-idr-l3nd-
	01.txt>.		02.txt>.
	[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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	DOI 10.17487/RFC4271, January 2006,		DOI 10.17487/RFC4271, January 2006,
	<https://www.rfc-editor.org/info/rfc4271>.		<https://www.rfc-editor.org/info/rfc4271>.
End of changes. 22 change blocks.
	32 lines changed or deleted		39 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/