< draft-haberman-rpsl-reachable-test-04.txt		draft-haberman-rpsl-reachable-test-05.txt >
	IETF B. Haberman, Ed.		This Internet-Draft, draft-haberman-rpsl-reachable-test-04.txt, was published as a Proposed Standard, RFC 5934
	Internet-Draft JHU APL		(http://www.ietf.org/rfc/rfc5934.txt), on 2010-8-13.
	Intended status: Standards Track May 27, 2010
	Expires: November 28, 2010
	A Dedicated Routing Policy Specification Language Interface Identifier
	for Operational Testing
	draft-haberman-rpsl-reachable-test-04
	Abstract
	The deployment of new IP connectivity typically results in
	intermittent reachability for numerous reasons which are outside the
	scope of this document. In order to aid in the debugging of these
	persistent problems, this document proposes the creation of a new
	Routing Policy Specification Language attribute that allows a network
	to advertise an IP address which is reachable and can be used as a
	target for diagnostic tests (e.g., pings).
	Status of this Memo
	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 28, 2010.
	Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.
	Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. RPSL Extension for Diagnostic Address . . . . . . . . . . . . . 3
	3. Using the RPSL Pingable Attribute . . . . . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
	7.2. Informative References . . . . . . . . . . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction
	The deployment of new IP connectivity typically results in
	intermittent reachability for numerous reasons which are outside the
	scope of this document. In order to aid in the debugging of these
	persistent problems, this document proposes the creation of a new
	Routing Policy Specification Language attribute [RFC4012] that allows
	a network to advertise an IP address which is reachable and can be
	used as a target for diagnostic tests (e.g., pings).
	The goal of this diagnostic address is to provide operators a means
	to advertise selected hosts that can be targets of tests for such
	common issues as reachability and Path MTU discovery.
	The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].
	2. RPSL Extension for Diagnostic Address
	Network operators wishing to provide a diagnostic address for its
	peers, customers, etc. MAY advertise its existence via the Routing
	Policy Specification Language [RFC4012] [RFC2622]. The pingable
	attribute is a member of the route and route6 objects in the RPSL.
	The definition of the pingable attribute is shown in Figure 1.
	+-----------+-------------------+--------------+
	| Attribute | Value | Type |
	+-----------+-------------------+--------------+
	| pingable | <ipv6-address> or | optional, |
	| | <ipv4-address> | multi-valued |
	+-----------+-------------------+--------------+
	| ping-hdl | <nic-handle> | optional, |
	| | | multi-valued |
	+-----------+-------------------+--------------+
	Figure 1: pingable attribute specification
	The exact definitions of <ipv4-address> and <nic-handle> can be found
	in [RFC2622], while the definition of <ipv6-address> is in [RFC4012].
	The pingable attribute allows a network operator to advertise an IP
	address of a node which should be reachable from outside networks.
	This node can be used as a destination address for diagnostic tests.
	The address specified MUST fall within the IP address range
	advertised in the route/route6 object containing the pingable
	attribute. The ping-hdl provides a link to contact information for
	an entity capable of responding to queries concerning the specified
	IP address. An example of using the pingable attribute is shown in
	Figure 2.
	route6: 2001:DB8::/32
	origin: AS64500
	pingable: 2001:DB8::DEAD:BEEF
	ping-hdl: OPS4-RIPE
	Figure 2: pingable attribute example
	3. Using the RPSL Pingable Attribute
	The presence of one or more pingable attributes signals to network
	operators that the operator of the target network is providing the
	address(es) for external diagnostic testing. Tests involving the
	advertised address(es) SHOULD be rate limited to no more than ten
	probes in a five minute window unless prior arrangements are made
	with the maintainer of the attribute.
	4. IANA Considerations
	None.
	5. Security Considerations
	The use of routing registries based on RPSL requires a significant
	level of security. In-depth discussion of the authentication and
	authorization capabilities and weaknesses within RPSL is discussed in
	[RFC2725]. The application of authentication in RPSL is key
	considering the vulnerabilities that may arise from the abuse of the
	pingable attribute by nefarious actors. Additional RPSL security
	issues are discussed in the Security Considerations sections of
	[RFC2622] and [RFC4012].
	The publication of this attribute only explicitly signals the
	availability of an ICMP Echo Request/Echo Response service on the
	specified IP address. The operator, at his/her discretion, MAY
	deploy other services at the same IP address. These services may be
	impacted by the ping service given its publicity via the RPSL.
	While this document specifies that external users of the pingable
	attribute rate limit their probes, there is no guarantee that they
	will do so. Operators publicizing a pingable attribute are
	encouraged to deploy their own rate limiting for the advertised IP
	address in order to reduce the risk of a denial-of-service attack.
	Services, protocols, and ports on the advertised IP address should be
	filtered if they are not intended for external users.
	6. Acknowledgements
	Randy Bush and David Farmer provided the original concept for the
	pingable attribute and useful comments on preliminary versions of
	this draft. Joe Abley provided comments that justified moving the
	attribute to the route/route6 object and the inclusion of a point of
	contact. Larry Blunk, Tony Tauber, David Harrington, Nicolas
	Williams, Sean Turner, and Peter Saint-Andre provided useful comments
	to improve the document.
	7. References
	7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
	Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
	"Routing Policy Specification Language (RPSL)", RFC 2622,
	June 1999.
	[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
	Murphy, "Routing Policy System Security", RFC 2725,
	December 1999.
	[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
	"Routing Policy Specification Language next generation
	(RPSLng)", RFC 4012, March 2005.
	7.2. Informative References
	Author's Address
	Brian Haberman (editor)
	Johns Hopkins University Applied Physics Lab
	11100 Johns Hopkins Road
	Laurel, MD 20723-6099
	US
	Phone: +1 443 778 1319
	Email: brian@innovationslab.net
End of changes. 1 change blocks.
	0 lines changed or deleted		0 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/