< draft-ietf-ion-nhrp-vpn-02.txt		draft-ietf-ion-nhrp-vpn-03.txt >
	Internet Engineering Task Force Barbara A. Fox		Internet Engineering Task Force Barbara A. Fox
	INTERNET-DRAFT Equipe Communications		INTERNET-DRAFT Equipe Communications
	<draft-ietf-ion-nhrp-vpn-02.txt> Bernhard Petri		<draft-ietf-ion-nhrp-vpn-03.txt> Bernhard Petri
	Expires March, 2000 Siemens AG		Expires April, 2000 Siemens AG
	NHRP Support for Virtual Private Networks		NHRP Support for Virtual Private Networks
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 19 ¶
	When a VPN-aware NHRP device forwards a packet pertaining to a		When a VPN-aware NHRP device forwards a packet pertaining to a
	particular VPN, that device MUST be able to indicate the VPN either:		particular VPN, that device MUST be able to indicate the VPN either:
	a) explicitly through use of the VPN-specific LLC/SNAP header or		a) explicitly through use of the VPN-specific LLC/SNAP header or
	b) implictly through an indication via VPN signalling.		b) implictly through an indication via VPN signalling.
	This applies to NHC-NHS, NHS-NHS, and NHS-NHC control messages as		This applies to NHC-NHS, NHS-NHS, and NHS-NHC control messages as
	well as NHC-NHC shortcut traffic.		well as NHC-NHC shortcut traffic.
	For case a), the indication of the VPN-ID is via a VPN-specific		For case a), the indication of the VPN-ID is via a VPN-specific
	LLC/SNAP header specified in section 4.1 below. In the case of an		LLC/SNAP header specified in section 4.2 below. In the case of an
	underlying ATM network, see also section 8 of [2].		underlying ATM network, see also section 8 of [2].
	For case b), the method used to indicate the VPN-ID via VPN		For case b), the method used to indicate the VPN-ID via VPN
	signalling depends on the mechanisms available in the underlying		signalling depends on the mechanisms available in the underlying
	network and is outside the scope of this draft. A VPN-aware NHRP		network and is outside the scope of this draft. A VPN-aware NHRP
	entity using VPN signalling SHOULD NOT also indicate the VPN-ID		entity using VPN signalling SHOULD NOT also indicate the VPN-ID
	explicity for any PDU on the related path.		explicity for any PDU on the related path.
	In transiting an NHRP Server, the VPN identification MAY be forwarded		In transiting an NHRP Server, the VPN identification MAY be forwarded
	in a different format than was received, however, the same VPN-ID		in a different format than was received, however, the same VPN-ID
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	The NHRP Device Capabilities extension MUST be attached to all NHRP		The NHRP Device Capabilities extension MUST be attached to all NHRP
	Resolution Requests generated by a VPN-aware source NHRP entity. The		Resolution Requests generated by a VPN-aware source NHRP entity. The
	device SHOULD set the Source Capabilities field to indicate that it		device SHOULD set the Source Capabilities field to indicate that it
	supports VPNs. The compulsory bit MUST be set to zero, so that a		supports VPNs. The compulsory bit MUST be set to zero, so that a
	non-VPN-aware NHS may safely ignore the extension when forwarding the		non-VPN-aware NHS may safely ignore the extension when forwarding the
	request. In addition, the A-bit (see section 5.2.1 of [1]) SHOULD be		request. In addition, the A-bit (see section 5.2.1 of [1]) SHOULD be
	set to indicate that only authoritative next hop information is		set to indicate that only authoritative next hop information is
	desired to avoid non-authoritative replies from non-VPN-aware NHRP		desired to avoid non-authoritative replies from non-VPN-aware NHRP
	servers.		servers.
	NTERNET-DRAFT NHRP VPN Expires March 2000		NTERNET-DRAFT NHRP VPN Expires April 2000
	Since a non-VPN-aware NHS is not able to process the NHRP Device		Since a non-VPN-aware NHS is not able to process the NHRP Device
	Capability extension, Network Admistrators MUST avoid configurations		Capability extension, Network Admistrators MUST avoid configurations
	in which a VPN-aware NHRP Client is authoritatively served by a non-		in which a VPN-aware NHRP Client is authoritatively served by a non-
	VPN-aware NHRP Server.		VPN-aware NHRP Server.
	If an egress NHS receives an NHRP Resolution Request with an NHRP		If an egress NHS receives an NHRP Resolution Request with an NHRP
	Device Capability Extension included, it returns an NHRP Resolution		Device Capability Extension included, it returns an NHRP Resolution
	Reply with an indication of whether the destination is VPN-aware by		Reply with an indication of whether the destination is VPN-aware by
	correctly setting the target capabilities flag [see Section 4.2].		correctly setting the target capabilities flag [see Section 4.2].
	skipping to change at page 6, line 46 ¶		skipping to change at page 6, line 46 ¶
	corresponding NHRP Resolution Reply.		corresponding NHRP Resolution Reply.
	The NHRP Device Capabilities extension SHOULD NOT be included in the		The NHRP Device Capabilities extension SHOULD NOT be included in the
	NHRP Register Request and Reply messages.		NHRP Register Request and Reply messages.
	3.4 Error handling procedures		3.4 Error handling procedures
	If an NHRP entity receives a PDU with a VPN-ID indicated via VPN		If an NHRP entity receives a PDU with a VPN-ID indicated via VPN
	encapsulation which is in conflict to a VPN-ID earlier allocated to		encapsulation which is in conflict to a VPN-ID earlier allocated to
	that communication (e.g. via VPN signalling or administratively via		that communication (e.g. via VPN signalling or administratively via
	configuration), then the PDU MAY be silently dropped. If it is not		configuration), it SHOULD send back an NHRP error indication (see
	silently discarded, an NHRP error indication (see 5.2.7 of [1]) MUST		5.2.7 of [1]) to the sender indicating error code 16 (VPN mismatch).
	be returned to the sender indicating error code 16 (VPN mismatch).		However, in order to avoid certain security issues, an NHRP entity
			MAY instead silently drop the packet.
	If a VPN-aware NHRP entity receives a packet for a VPN that it does		If a VPN-aware NHRP entity receives a packet for a VPN that it does
	not support, the packet MAY be silently dropped. If it is not		not support, it SHOULD send back an NHRP error indication to the
	discarded silently, an NHRP error indication MUST be returned to the		sender with an error code 17 (VPN not supported). However, in order
	sender with an error code 17 (VPN not supported).		to avoid certain security issues, an NHRP entity MAY instead silently
			drop the packet.
	If a VPN-aware NHS cannot find a route to forward a VPN-related NHRP		If a VPN-aware NHS cannot find a route to forward a VPN-related NHRP
	message, the packet MAY be silently dropped. If it is not discarded		message, it SHOULD send back an NHRP error indication to the sender
	silently, it MAY send back an NHRP error indication with error code 6		with error code 6 (protocol address unreachable). However, in order
	(protocol address unreachable).		to avoid certain security issues, an NHRP entity MAY instead silently
			drop the packet.
	In all cases, where an NHRP error indication is returned by a VPN-		In all cases, where an NHRP error indication is returned by a VPN-
	aware NHRP entity, the incorrect VPN-ID related to this indication		aware NHRP entity, the incorrect VPN-ID related to this indication
	SHALL be indicated via VPN encapsulation or VPN signalling, except		SHALL be indicated via VPN encapsulation or VPN signalling, except
	when sending it to a non-VPN-aware NHRP device (see 3.1 above).		when sending it to a non-VPN-aware NHRP device (see 3.1 / 3.2 above).
	4. NHRP Packet Formats		4. NHRP Packet Formats
	4.1 VPN encapsulation		4.1 VPN encapsulation
	The format of the VPN encapsulation header is as follows:		The format of the VPN encapsulation header is 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 9, line 23 ¶		skipping to change at page 9, line 23 ¶
	| Source Capabilities |		| Source Capabilities |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Target Capabilities |		| Target Capabilities |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	C: Compulsory = 0 (not a compulsory extension)		C: Compulsory = 0 (not a compulsory extension)
	u: Unused and MUST be set to zero.		u: Unused and MUST be set to zero.
	Type = 0x0009		Type = 0x0009
	Length = 0x0008		Length = 0x0008
	Source Capabilities:		Source Capabilities field:
	0x00000000 - the source NHRP device is non-VPN-aware
	0x00000001 - the source NHRP device is VPN-aware
	Target Capabilities:		0 1 2 3
	0x00000000 - the destination NHRP device is non-VPN-aware		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
	0x00000001 - the destination NHRP device is VPN-aware		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| unused |V|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			V bit:
			0x0 - the source NHRP device is non-VPN-aware
			0x1 - the source NHRP device is VPN-aware
			The unused bits MUST be set to zero on transmission
			and ignored on receipt.
			Target Capabilities field:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| unused |V|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			V bit:
			0x0 - the destination NHRP device is non-VPN-aware
			0x1 - the destination NHRP device is VPN-aware
			The unused bits MUST be set to zero on transmission
			and ignored on receipt.
	4.3 Error Codes		4.3 Error Codes
	The following further Error Codes are defined in addition to those		The following further Error Codes are defined in addition to those
	specified in section 5.2.7 of [1]):		specified in section 5.2.7 of [1]):
	16 - VPN mismatch		16 - VPN mismatch
	This error code is returned by a VPN-capable NHRP device, if it		This error code is returned by a VPN-capable NHRP device, if it
	receives a PDU with a VPN-ID in the LLC/SNAP header different		receives a PDU with a VPN-ID in the LLC/SNAP header different
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 39 ¶
	5. Security considerations		5. Security considerations
	For any VPN application, it is important that VPN-related information		For any VPN application, it is important that VPN-related information
	is not misdirected to other VPNs and is not accessible when being		is not misdirected to other VPNs and is not accessible when being
	transferred across a public or shared infrastructure. It is therefore		transferred across a public or shared infrastructure. It is therefore
	RECOMMENDED to use the VPN support functions specified in this		RECOMMENDED to use the VPN support functions specified in this
	document in combination with NHRP authentication as specified in		document in combination with NHRP authentication as specified in
	section 5.3.4 of [1]. Section 5.3.4.4 of [1] also provides further		section 5.3.4 of [1]. Section 5.3.4.4 of [1] also provides further
	information on general security considerations related to NHRP.		information on general security considerations related to NHRP.
			In cases where the NHRP entity does not trust all of the NHRP
			entities, or is uncertain about the availability of the end-to-end
			NHRP authentication chain, it may use IPsec for confidentiality,
			integrity, etc.
	6. IANA considerations		6. IANA considerations
	The LLC/SNAP protocol ID 0x00-08 for VPN encapsulation had already		The LLC/SNAP protocol ID 0x00-08 for VPN encapsulation had already
	been allocated by IANA in conjunction with [2]. This specification		been allocated by IANA in conjunction with [2]. This specification
	does not require the allocation of any additional LLC/SNAP protocol		does not require the allocation of any additional LLC/SNAP protocol
	IDs beyond that.		IDs beyond that.
	It should be noted that IANA - as the owner of the VPN-related OUI:		It should be noted that IANA - as the owner of the VPN-related OUI:
	0x00-00-5E - is itself also a VPN authority which may allocate VPN		0x00-00-5E - is itself also a VPN authority which may allocate VPN
	indices to identify VPNs. The use of these particular VPN indices		indices to identify VPNs. The use of these particular VPN indices
	within the context of this specification is reserved, and requires		within the context of this specification is reserved, and requires
	allocation and approval by IANA.		allocation and approval by the IESG in accordance with RFC 2434.
	References		References
	[1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and		[1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and
	N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC		N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC
	2332, April 1998.		2332, April 1998.
	[2] Grossman, D. and Heinanen, J. "Multiprotocol Encapsulation over ATM		[2] Grossman, D. and Heinanen, J. "Multiprotocol Encapsulation over ATM
	Adaptation Layer 5", RFC 2684, September 1999.		Adaptation Layer 5", RFC 2684, September 1999.
	[3] Fox, B., Gleeson, B., "Virtual Private Networks Identifier", RFC 2685,		[3] Fox, B., Gleeson, B., "Virtual Private Networks Identifier", RFC 2685,
	September 1999.		September 1999.
	Author Information		Author Information
	Barbara A. Fox		Barbara A. Fox
	Equipe Communications		Equipe Communications
	100 Nagog Park		101 Nagog Park
	Acton, MA 01720		Acton, MA 01720
	phone: +1-978-635-1999 x2009		phone: +1-978-635-1999 x2009
	email: bfox@equipecom.com		email: bfox@equipecom.com
	Bernhard Petri		Bernhard Petri
	Siemens AG		Siemens AG
	Hofmannstr. 51		Hofmannstr. 51
	Munich, Germany, D-81359		Munich, Germany, D-81359
	phone: +49 89 722-34578		phone: +49 89 722-34578
	email: bernhard.petri@icn.siemens.de		email: bernhard.petri@icn.siemens.de
End of changes. 12 change blocks.
	22 lines changed or deleted		53 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/