1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc5943.txt b/doc/rfc/rfc5943.txt
new file mode 100644
index 0000000..a3fbb94
--- /dev/null
+++ b/doc/rfc/rfc5943.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                  B. Haberman, Ed.
+Request for Comments: 5943                                       JHU APL
+Category: Standards Track                                    August 2010
+ISSN: 2070-1721
+
+
+ A Dedicated Routing Policy Specification Language Interface Identifier
+                        for Operational Testing
+
+Abstract
+
+   The deployment of new IP connectivity typically results in
+   intermittent reachability for numerous reasons that 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 that is reachable and can be used as a
+   target for diagnostic tests (e.g., pings).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5943.
+
+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.
+
+
+
+
+Haberman                     Standards Track                    [Page 1]
+
+RFC 5943                 RPSL Pingable Attribute             August 2010
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  RPSL Extension for Diagnostic Address . . . . . . . . . . . . . 2
+   3.  Using the RPSL Pingable Attribute . . . . . . . . . . . . . . . 3
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
+   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
+   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 4
+
+1.  Introduction
+
+   The deployment of new IP connectivity typically results in
+   intermittent reachability for numerous reasons that 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 that 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 their
+   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
+
+
+
+
+Haberman                     Standards Track                    [Page 2]
+
+RFC 5943                 RPSL Pingable Attribute             August 2010
+
+
+   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 that 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.  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 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.
+
+
+
+
+
+
+Haberman                     Standards Track                    [Page 3]
+
+RFC 5943                 RPSL Pingable Attribute             August 2010
+
+
+   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.
+
+5.  Acknowledgements
+
+   Randy Bush and David Farmer provided the original concept for the
+   pingable attribute and useful comments on preliminary versions of
+   this document.  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.
+
+6.  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.
+
+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
+
+
+
+
+
+Haberman                     Standards Track                    [Page 4]
+