Movatterモバイル変換

Internet Engineering Task Force (IETF)                  B. Haberman, Ed.Request for Comments: 5943                                       JHU APLCategory: Standards Track                                    August 2010ISSN: 2070-1721A Dedicated Routing Policy Specification Language Interface Identifierfor Operational TestingAbstract   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 inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://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 toBCP 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 2010Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .22.  RPSL Extension for Diagnostic Address . . . . . . . . . . . . .23.  Using the RPSL Pingable Attribute . . . . . . . . . . . . . . .34.  Security Considerations . . . . . . . . . . . . . . . . . . . .35.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .46.  Normative References  . . . . . . . . . . . . . . . . . . . . .41.  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 SpecificationHaberman                     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 Example3.  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.netHaberman                     Standards Track                    [Page 4]