mp-peer <protocol> <ipv4-address> <options> or optional,
<protocol> <ipv6-address> <options> or multi-valued
<protocol> <inet-rtr-name> <options> or
<protocol> <rtr-set-name> <options> or
<protocol> <peering-set-name> <options>
where <protocol> is a protocol name, and <options> is a
comma-separated list of peering options for <protocol>, as provided
in the RPSL dictionary.
4.6. rtr-set Class
The rtr-set class is extended with a new attribute, "mp-members:".
This attribute extends the original "members:" attribute by allowing
the specification of IPv6 addresses. It is defined as follows:
Attribute Value Type
mp-members list of (<inet-rtr-name> or optional, multi-valued
<rtr-set-name> or
<ipv4-address> or
<ipv6-address>)
5. RFC 2725 Extensions
RFC 2725 [2] introduces an authorization model to address the
integrity of policy expressed in routing registries. Two new
attributes were defined to support this authorization model: the
"mnt-routes" and "mnt-lower" attributes.
In RPSLng, these attributes are extended to the route6 and inet6num
(described below) classes. Further, the syntax of the existing mnt-
routes attribute is modified to allow the optional specification of
IPv6 prefix range lists when present in inet6num, route6, and aut-num
class objects. This optional list of prefix ranges is a comma-
separated list enclosed in curly braces. In the aut-num class, the
IPv6 prefix ranges may be mixed with IPv4 prefix ranges. The keyword
"ANY" may also be used instead of prefix ranges. In the case of
inet6num and route6 objects, "ANY" refers to all more specifics of
the prefix in the class key field. For the aut-num class, "ANY"
literally means any prefix. The default when no additional set items
are specified is "ANY". An abbreviated definition of the aut-num
class with the updated syntax for the mnt-routes attribute is
presented below.
Attribute Value Type
aut-num <as-number> mandatory, class key,
single-valued
mnt-routes list of <mntner-name> optional, multi-valued
[{list of (<ipv6-address-prefix-range> or
<ipv4-address-prefix-range>)} or ANY]
The following is an example of mnt-routes usage. This example
authorizes MAINT-65001 to create route6 objects with an origin AS of
65002 for IPv6 address prefixes within the 2001:0DB8::/32^+ range,
and route objects with origin AS 65002 for IPv4 prefixes within the
192.0.2.0/24^+ range.
aut-num: AS65002
mnt-routes: MAINT-AS65001 {2001:0DB8::/32^+, 192.0.2.0/24^+}
Note, that the inclusion of IPv6 prefix ranges within a mnt-routes
attribute in an aut-num object may conflict with existing
implementations of RPSL that support only IPv4 prefix ranges.
However, given the perceived lack of implementation of this optional
prefix range list, it was considered more acceptable to extend the
existing definition of the mnt-routes attribute in the aut-num class
rather than to create a new attribute type.
Attribute Value Type
inet6num <ipv6-address-prefix> mandatory, single-valued,
class key
netname <netname> mandatory, single-valued
descr <free-form> mandatory, multi-valued
country <country-code> mandatory, multi-valued
admin-c <nic-handle> mandatory, multi-valued
tech-c <nic-handle> mandatory, multi-valued
remarks <free-form> optional, multi-valued
notify <email-address> optional, multi-valued
mnt-lower list of <mntner-name> optional, multi-valued
mnt-routes list of <mntner-name> optional, multi-valued
[{list of <ipv6-address-prefix-range>} or ANY]
mnt-by list of <mntner-name> mandatory, multi-valued
changed <email-address> <date> mandatory, multi-valued
source <registry-name> mandatory, single-valued
The <country-code> must be a valid two-letter ISO 3166 country code
identifier. <netname> is a symbolic name for the specified IPv6
address space. It does not have a restriction on RPSL reserved
prefixes. These definitions are taken from the RIPE Database
Reference Manual [4].
5.1. Authorization Model for route6 Objects
Deletion and update of a route6 object is not different from other
objects, as defined in RFC 2725 [2]. Creation rules of a route6
object is replicated here from the corresponding rules for route
object in RFC 2725 [2] section 9.9.
When a route6 object is added, the submission must satisfy two
authentication criteria. It must match the authentication specified
in the aut-num object and that specified in either a route6 object
or, if no applicable route6 object is found, an inet6num object.
An addition is submitted with an AS number and IPv6 prefix as its
key. If the aut-num object does not exist on a route6 to add, then
the addition is rejected. If the aut-num exists, then the submission
is checked against the applicable maintainers. A search is then done
for the prefix, looking first for an exact match and then, failing
that, for the longest prefix match less specific than the prefix
specified. If this search succeeds, it will return one or more
route6 objects. The submission must match an applicable maintainer
in at least one of these route6 objects for the addition to succeed.
If the search for a route6 object fails, then a search is performed
for an inet6num object that exactly matches the prefix, or for the
most specific inet6num less specific than the route6 object
submission.
Once the aut-num and either a list of route6 objects or an inet6num
is found, the authorization is taken from these objects. The
applicable maintainer object is any referenced by the mnt-routes
attributes. If one or more mnt-routes attributes are present in an
object, the mnt-by or mnt-lower attributes are not considered. In
the absence of a mnt-routes attribute in a given object, the first
mnt-lower attributes are used (only if the given object is an
inet6num object and it is less specific than the route6 object to be
added). If no applicable mnt-lower attribute is found, then the
mnt-by attributes are used for that object. The authentication must
match one of the authorizations in each of the two objects.
6. Security Considerations
This document describes extensions to RFC 2622 [1] and RFC 2725 [2].
The extensions address the limitations of the aforementioned
documents with respect to IPv6 and multicast. The extensions do not
introduce any new security functionality or threats.
Although the extensions introduce no additional security threats, it
should be noted that the original RFC 2622 [1] RPSL standard included
several weak and/or vulnerable authentication mechanisms: first, the
"MAIL-FROM" scheme, which can be easily defeated via source email
address spoofing; second, the "CRYPT-PW" scheme, which is subject to
dictionary attacks and password sniffing if RPSL objects are
submitted via unencrypted channels such as email; and, finally, the
"NONE" mechanism, which offers no protection for objects.
7. Acknowledgements
The authors wish to thank all the people who have contributed to this
document through numerous discussions, particularly Ekaterina
Petrusha, for highly valuable discussions and suggestions: Shane
Kerr, Engin Gunduz, Marc Blanchet, and David Kessens who participated
constructively in many discussions and Cengiz Alaettinoglu, who is
still the reference in all things RPSL.
8. References
8.1. Normative References
[1] 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.
[2] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy,
"Routing Policy System Security", RFC 2725, December 1999.
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
8.2. Informative References
[4] Damas, J. and A. Robachevsky, "RIPE Database Reference Manual",
August 2002.
Authors’ Addresses
Larry Blunk
Merit Network
EMail: ljb@merit.edu
Joao Damas
Internet Systems Consortium
EMail: Joao_Damas@isc.org
Florent Parent
Hexago
EMail: Florent.Parent@hexago.com
Andrei Robachevsky
RIPE NCC
EMail: andrei@ripe.net
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.