doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc4012.txt b/doc/rfc/rfc4012.txt
new file mode 100644
index 0000000..88feb0e
--- /dev/null
+++ b/doc/rfc/rfc4012.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                           L. Blunk
+Request for Comments: 4012                                 Merit Network
+Updates: 2725, 2622                                             J. Damas
+Category: Standards Track                    Internet Systems Consortium
+                                                               F. Parent
+                                                                  Hexago
+                                                          A. Robachevsky
+                                                                RIPE NCC
+                                                              March 2005
+
+
+     Routing Policy Specification Language next generation (RPSLng)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This memo introduces a new set of simple extensions to the Routing
+   Policy Specification Language (RPSL), enabling the language to
+   document routing policies for the IPv6 and multicast address families
+   currently used in the Internet.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Specifying routing policy for different address families . . .  2
+       2.1.  Ambiguity Resolution . . . . . . . . . . . . . . . . . .  3
+       2.2.  The afi dictionary attribute . . . . . . . . . . . . . .  3
+       2.3.  RPSL dictionary extensions . . . . . . . . . . . . . . .  4
+       2.4.  IPv6 RPSL types  . . . . . . . . . . . . . . . . . . . .  4
+       2.5.  mp-import, mp-export, and mp-default . . . . . . . . . .  4
+             2.5.1.  <mp-peering> . . . . . . . . . . . . . . . . . .  6
+             2.5.2.  <mp-filter>  . . . . . . . . . . . . . . . . . .  6
+             2.5.3.  Policy examples  . . . . . . . . . . . . . . . .  7
+   3.  route6 Class . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   4.  Updates to existing Classes to support the extensions  . . . .  8
+       4.1.  as-set Class . . . . . . . . . . . . . . . . . . . . . .  8
+       4.2.  route-set Class  . . . . . . . . . . . . . . . . . . . .  9
+
+
+
+Blunk, et al.               Standards Track                     [Page 1]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+       4.3.  filter-set Class . . . . . . . . . . . . . . . . . . . .  9
+       4.4.  peering-set Class  . . . . . . . . . . . . . . . . . . .  9
+       4.5.  inet-rtr Class . . . . . . . . . . . . . . . . . . . . . 10
+       4.6.  rtr-set Class  . . . . . . . . . . . . . . . . . . . . . 11
+   5.  RFC 2725 Extensions  . . . . . . . . . . . . . . . . . . . . . 11
+       5.1.  Authorization model for route6 Objects . . . . . . . . . 13
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+       8.1.  Normative References . . . . . . . . . . . . . . . . . . 14
+       8.2.  Informative References . . . . . . . . . . . . . . . . . 14
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
+       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
+
+1.  Introduction
+
+   RFC 2622 [1] defines the RPSL language for the IPv4 unicast routing
+   protocols and provides a series of guidelines for extending the RPSL
+   language itself.  Additionally, security extensions to the RPSL
+   language are specified in RFC 2725 [2].
+
+   This document proposes to extend RPSL according to the following
+   goals and requirements:
+
+   o  Provide RPSL extensibility in the dimension of address families,
+      specifically, to allow users to document routing policy for IPv6
+      and multicast.
+   o  Extensions should be backward compatible with minimal impact on
+      existing tools and processes, following Section 10 of RFC 2622 [1]
+      for guidelines on extending RPSL.
+   o  Maintain clarity and non-ambiguity: RPSL information is used by
+      humans in addition to software tools.
+   o  Minimize duplication of information, particularly when routing
+      policies for different address families are the same.
+
+   The addition of IPv6 and multicast support to RPSL leads to four
+   distinct routing policies that need to be distinguished in this
+   specification, namely, (IPv4 {unicast|multicast}, IPv6
+   {unicast|multicast}).
+
+2.  Specifying Routing Policy for Different Address Families
+
+   Routing policy is currently specified in the aut-num class using
+   "import:", "export:", and "default:" attributes.  Sometimes it is
+   important to distinguish policy for different address families, as
+   well as a unicast routing policy from a multicast one.
+
+
+
+
+
+Blunk, et al.               Standards Track                     [Page 2]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+   Although the syntax of the existing import, export, and default
+   attributes could be extended, this would present backward
+   compatibility issues and could undermine clarity in the expressions.
+
+   Keeping this in mind, the "import:", "export:", and "default:"
+   attributes implicitly specify IPv4 unicast policy and will remain as
+   previously defined in RPSL, and new multi-protocol (prefixed with the
+   string "mp-") attributes will be introduced.  These new "mp-"
+   attributes are described below.
+
+2.1.   Ambiguity Resolution
+
+   The same peering can be covered by more than one multi-protocol
+   policy attribute or by a combination of multi-protocol policy
+   attributes (when specifying IPv4 unicast policy) and the previously
+   defined IPv4 unicast policy attributes.  In these cases,
+   implementations should follow the specification-order rule as defined
+   in Section 6.4 of RFC 2622 [1].  To break the ambiguity, the action
+   corresponding to the first peering specification is used.
+
+2.2.  The afi Dictionary Attribute
+
+   This section introduces a new dictionary attribute:
+
+   Address Family Identifier, <afi>, is an RPSL list of address families
+   for which a given routing policy expression should be evaluated.
+   <afi> is optional within the new multi-protocol attributes introduced
+   in the aut-num class.  A pseudo identifier named "any" is defined to
+   allow for more compact policy expressions with converged routing
+   policy.
+
+   The possible values for <afi> are as follows:
+
+      ipv4.unicast
+      ipv4.multicast
+      ipv4 (equivalent to ipv4.unicast, ipv4.multicast)
+      ipv6.unicast
+      ipv6.multicast
+      ipv6 (equivalent to ipv6.unicast, ipv6.multicast)
+      any (equivalent to ipv4, ipv6)
+      any.unicast (equivalent to ipv4.unicast, ipv6.unicast)
+      any.multicast (equivalent to ipv4.multicast, ipv6.multicast)
+
+   Appearance of these values in an attribute must be preceded by the
+   keyword afi.
+
+   An <afi-list> is defined as a comma-separated list of one or more afi
+   values.
+
+
+
+Blunk, et al.               Standards Track                     [Page 3]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+2.3.  RPSL Dictionary Extensions
+
+   In order to support IPv6 addresses specified with the next-hop rp-
+   attribute, a new predefined dictionary type entitled "ipv6_address"
+   is added to the RPSL dictionary.  The definition of this type is
+   taken from Section 2.2 of RFC 3513 [3].
+
+   The next-hop rp-attribute is expanded in the dictionary as follows:
+
+   rp-attribute: # next hop router in a static route
+                 next-hop
+                 operator=(union ipv4_address, ipv6_address, enum[self])
+
+   A new value has been added for the <protocol> dictionary
+   specification:
+      MPBGP
+
+   MPBGP is understood to be BGP4 with multi-protocol extensions (often
+   referred to as BGP4+).  BGP4+ could not be used, as the '+' character
+   is not allowed by the RPSL specification in protocol names.
+
+2.4.  IPv6 RPSL Types
+
+   This document will reference three new IPv6 RPSL types, namely,
+   <ipv6-address>, <ipv6-address-prefix>, and <ipv6-address-prefix-
+   range>.  The <ipv6-address> and <ipv6-address-prefix> types are
+   defined in Sections 2.2 and 2.3 of RFC 3513 [3].  The <ipv6-address-
+   prefix-range> type adds a range operator to the <ipv6-address-prefix>
+   type.  The range operator is defined in Section 2 of RFC 2622 [1].
+
+2.5.  mp-import, mp-export, and mp-default
+
+   Three new policy attributes are introduced in the aut-num Class:
+
+      mp-import:
+      mp-export:
+      mp-default:
+
+   These attributes incorporate the afi (address-family) specification.
+   Note that the afi specification is optional.  If no afi specification
+   is present, the policy expression is presumed to apply to all
+   protocol families, namely, ipv4.unicast, ipv4.multicast,
+   ipv6.unicast, and ipv6.multicast.  This is the equivalent of the afi
+   specification "afi any".  The mp-import and mp-export attributes have
+   both a basic policy specification and a more powerful structured
+   policy specification.
+
+
+
+
+
+Blunk, et al.               Standards Track                     [Page 4]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+   The syntax for the mp-default attribute and the basic policy
+   specification of the mp-import and mp-export attributes is as
+   follows:
+
+   Attribute  Value                                         Type
+   mp-import  [protocol <protocol-1>] [into <protocol-2>]   optional,
+              [afi <afi-list>]                              multi-valued
+              from <mp-peering-1> [action <action-1>; ... <action-N>;]
+              . . .
+              from <mp-peering-M> [action <action-1>; ... <action-N>;]
+              accept <mp-filter> [;]
+
+   mp-export  [protocol <protocol-1>] [into <protocol-2>]   optional,
+              [afi <afi-list>]                              multi-valued
+              to <mp-peering-1> [action <action-1>; ... <action-N>;]
+              . . .
+              to <mp-peering-M> [action <action-1>; ... <action-N>;]
+              announce <mp-filter> [;]
+
+   mp-default [afi <afi-list>] to <mp-peering>              optional,
+              [action <action-1>; ... <action-N>;]          multi-valued
+              [networks <mp-filter>]
+
+   The mp-import and mp-export policies can be structured.  As with RFC
+   2622 [1], structured policies are recommended only to advanced RPSL
+   users.  The mp-import structured policy syntax is defined below.
+   Please note the semicolon at the end of an <import-factor> is
+   mandatory for structured policy expressions, while being optional on
+   non-structured policy expressions.  The mp-export structured policy
+   syntax is expressed symmetrically to the mp-import attribute.  The
+   structured syntax allows exceptions and refinements to policies by
+   use of the "except" and "refine" keywords.  Further, the exceptions
+   and refinements may specify an optional "afi" list to restrict the
+   policy expression to particular address families.
+
+   Note that the definition allows subsequent or "cascading" refinements
+   and exceptions.  RFC 2622 [1] incorrectly refers to these as "nested"
+   expressions.  The syntax does not allow true nested expressions.
+
+   <import-factor> ::=
+        from <mp-peering-1> [action <action-1>; ... <action-M>;]
+        . . .
+        from <mp-peering-N> [action <action-1>; ... <action-K>;]
+        accept <mp-filter>;
+
+   <import-term> :: = import-factor |
+        {
+        <import-factor-1>
+
+
+
+Blunk, et al.               Standards Track                     [Page 5]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+        . . .
+        <import-factor-N>
+        }
+
+   <import-expression> ::= <import-term> |
+        <import-term> EXCEPT <afi-import-expression> |
+        <import-term> REFINE <afi-import-expression>
+
+   <afi-import-expression> ::= [afi <afi-list>] <import-expression>
+
+   mp-import: [protocol <protocol-1>] [into <protocol-2>]
+        <afi-import-expression>
+
+2.5.1.  <mp-peering>
+
+   <mp-peering> indicates the AS (and the router if present) and is
+   defined as follows:
+
+   <mp-peering> ::= <as-expression> [<mp-router-expression-1>]
+                    [at <mp-router-expression-2>] | <peering-set-name>
+
+   where <as-expression> is an expression over AS numbers and AS sets
+   using operators AND, OR, and EXCEPT, and <mp-router-expression> is an
+   expression over router ipv4-addresses or ipv6-addresses, inet-rtr
+   names, and rtr-set names using operators AND, OR, and EXCEPT.  The
+   binary "EXCEPT" operator is the set subtraction operator and has the
+   same precedence as the operator AND (it is semantically equivalent to
+   "AND NOT" combination).  That is, "(AS65001 OR AS65002) EXCEPT
+   AS65002" equals "AS65001".
+
+2.5.2.  <mp-filter>
+
+   The <mp-filter> policy filter expression is derived from the RPSL
+   <filter> policy filter expression defined in section 5.4 of RFC 2622
+   [1].  <mp-filter> extends the <filter> expression to allow the
+   specification of IPv6 prefixes and prefix ranges.  In particular, an
+   Address-Prefix Set expression in an <mp-filter> expression may
+   include both IPv4 and IPv6 prefixes or prefix ranges.  <mp-filter> is
+   otherwise identical to the RPSL <filter> expression.  Address-Prefix
+   Sets are enclosed in braces, '{' and '}'.  The policy filter matches
+   the set of routes whose destination address-prefix is in the set.
+   For example:
+
+      { 192.0.2.0/24, 2001:0DB8::/32 }
+      { 2001:0DB8:0100::/48^+, 2001:0DB8:0200::/48^64 }
+
+
+
+
+
+
+Blunk, et al.               Standards Track                     [Page 6]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+2.5.3.  Policy Examples
+
+   The address family may be specified in subsequent refine or except
+   policy expressions and is valid only within the policy expression
+   that contains it.
+
+   Therefore, in the example
+
+   aut-num:    AS65534
+   mp-import: afi any.unicast from AS65001 accept as-foo;
+                except afi any.unicast {
+                  from AS65002 accept AS65226;
+                } except afi ipv6.unicast {
+                    from AS65003 accept {2001:0DB8::/32};
+                  }
+
+   the last "except" is evaluated only for the IPv6 unicast address
+   family, while other import-expressions are evaluated for both the
+   IPv6 and IPv4 unicast address families.
+
+   The evaluation of a policy expression is done by evaluating each of
+   its components.  Evaluation of peering-sets and filter-sets is
+   constrained by the address family.  Such constraints may result in a
+   "NOT ANY" <mp-filter> or invalid <mp-peering> depending on implicit
+   or explicit definitions of the address family in the set.  Conflicts
+   with explicit or implicit declarations are resolved at runtime during
+   the evaluation of a policy expression.  An RPSL evaluation
+   implementation may wish to issue a warning in the case of a "NOT ANY"
+   <mp-filter>.  The following mp-import policy contains an example of
+   an <mp-filter> that should be evaluated as "NOT ANY":
+
+   aut-num: AS65002
+   mp-import: afi ipv6.unicast from AS65001 accept {192.0.2.0/24}
+
+3.  route6 Class
+
+   The route6 class is the IPv6 equivalent of the route class.  As with
+   the route class, the class key for the route6 class is specified by
+   the route6 and origin attribute pair.  Other than the route6
+   attribute, the route6 class shares the same attribute names with the
+   route class.  Although the attribute names remain identical, the
+   inject, components, exports-comps, holes, and mnt-routes attributes
+   must specify IPv6 prefixes and addresses rather than IPv4 prefixes
+   and addresses.  This requirement is reflected by the specification of
+   <ipv6-router-expression>, <ipv6-filter>, and <ipv6-address-prefix>
+   below.  <ipv6-address-prefix> has been previously defined.  <ipv6-
+   filter> is related to <mp-filter> as defined above in Section 2.5.2,
+   with the exception that only <ipv6-address-prefix> types are
+
+
+
+Blunk, et al.               Standards Track                     [Page 7]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+   permitted.  Similarly, <ipv6-router-expression> is related to
+   <mp-router-expression> as defined above in Section 2.5.1 with the
+   exception that only <ipv6-address> types are permitted.
+
+Attribute     Value                             Type
+route6        <ipv6-address-prefix>             mandatory, class key,
+                                                single-valued
+origin        <as-number>                       mandatory, class key,
+                                                single-valued
+member-of     list of <route-set-name>          optional, multi-valued
+inject        [at <ipv6-router-expression>] ... optional, multi-valued
+              [action <action>]
+              [upon <condition>]
+components    [ATOMIC] [[<ipv6-filter>]         optional, single-valued
+              [protocol <protocol> <ipv6-filter> ...]]
+aggr-bndry    <as-expression>                   optional, single-valued
+aggr-mtd      inbound or outbound               optional, single-valued
+              [<as-expression>]
+export-comps  <ipv6-filter>                     optional, single-valued
+holes         list of <ipv6-address-prefix>     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]
+
+   Example:
+
+   route6:   2001:0DB8::/32
+   origin:   AS65001
+
+4.  Updates to Existing Classes to Support the Extensions
+
+4.1.  as-set Class
+
+   The as-set class defines a set of Autonomous Systems (AS), specified
+   either directly by listing them in the members attribute or
+   indirectly by referring to another as-set or using the mbrs-by-ref
+   facility.  More importantly, "In a context that expects a route set
+   (e.g., members attribute of the route-set class), [...] an as-set
+   AS-X defines the set of routes that are originated by the ASes in
+   AS-X", (section 5.3 of  RFC 2622 [1]).
+
+   The as-set class is therefore used to collect a set of route
+   prefixes, which may be restricted to a specific address family.
+
+   The existing as-set class does not need any modifications.  The
+   evaluation of the class must be filtered to obtain prefixes belonging
+   to a particular address family using the traditional filtering
+   mechanism in use in Internet Routing Registry (IRR) systems today.
+
+
+
+Blunk, et al.               Standards Track                     [Page 8]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+4.2.  route-set Class
+
+   This class is used to specify a set of route prefixes.
+
+   A new attribute "mp-members:" is defined for this class.  This
+   attribute allows the specification of IPv4 or IPv6
+   address-prefix-ranges.
+
+Attribute   Value                                 Type
+mp-members  list of (<ipv4-address-prefix-range>  optional, multi-valued
+            or <ipv6-address-prefix-range>
+            or <route-set-name>
+            or <route-set-name><range-operator>)
+
+Example:
+
+route-set:  rs-foo
+mp-members: rs-bar
+mp-members: 2001:0DB8::/32  # v6 member
+mp-members: 192.0.2.0/24   # v4 member
+
+4.3.  filter-set Class
+
+   The new "mp-filter:" attribute defines the set's policy filter.  A
+   policy filter is a logical expression that when applied to a set of
+   routes returns a subset of these routes.  The relevant parts of the
+   updated filter-set class are shown below:
+
+   Attribute   Value                Type
+   filter-set  <object-name>        mandatory, single-valued, class key
+   filter      <filter>             optional, single-valued
+   mp-filter   <mp-filter>          optional, single-valued
+
+   Where <mp-filter> is defined above in Section 2.5.2.  While the
+   "filter:" and "mp-filter:" attributes are of type "optional", a
+   filter-set must contain one of these two attributes.  Implementations
+   should reject instances where both attributes are defined in an
+   object, as the interpretation of such a filter-set is undefined.
+
+4.4.  peering-set Class
+
+   The peering set class is updated with a "mp-peering:" attribute.
+
+   Attribute    Value               Type
+   peering-set  <object-name>       mandatory, single-valued, class key
+   peering      <peering>           optional, multi-valued
+   mp-peering   <mp-peering>        optional, multi-valued
+
+
+
+
+Blunk, et al.               Standards Track                     [Page 9]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+   Example:
+
+   peering-set:   prng-ebgp-peers
+   mp-peering:    AS65002 2001:0DB8::1 at 2001:0DB8::2
+
+   With <mp-peering> defined as above in Section 2.5.1.  While the
+   "peering:" and "mp-peering:" attributes are of type "optional", a
+   peering-set must contain at least one of these two attributes.
+
+4.5.  inet-rtr Class
+
+   Two new attributes are introduced to the inet-rtr class --
+   "interface:", which allows the definition of generic interfaces,
+   including the information previously contained in the "ifaddr:"
+   attribute, as well as support for tunnel definitions;  and "mp-
+   peer:", which includes and extends the functionality of the existing
+   "peer:" attribute.  The syntax definition for the "interface:"
+   attribute follows:
+
+   Attribute  Value                               Type
+   interface  <ipv4-address> or <ipv6-address>    optional, multi-valued
+              masklen <mask>
+              [action <action>]
+              [tunnel <remote-endpoint-address>,<encapsulation>]
+
+   The syntax allows native IPv4 and IPv6 interface definitions, as well
+   as the definition of tunnels as virtual interfaces.  Without the
+   optional tunnel definition, this attribute allows the same
+   functionality as the "ifaddr:" attribute but extends it to allow IPv6
+   addresses.
+
+   If the interface is a tunnel, the syntax is as follows:
+
+   <remote-endpoint-address> indicates the IPv4 or IPv6 address of the
+   remote endpoint of the tunnel.  The address family must match that of
+   the local endpoint.  <encapsulation> denotes the encapsulation used
+   in the tunnel and is one of {GRE,IPinIP} (note that the outer and
+   inner IP protocol versions can be deduced from the interface context
+   -- for example, IPv6-in-IPv4 encapsulation is just IPinIP).  Routing
+   policies for these routers should be described in the appropriate
+   classes (e.g., aut-num).
+
+   The "mp-peer:" attribute is defined below.  The difference between
+   this attribute and the "peer:" attribute is the inclusion of support
+   for IPv6 addresses.
+
+
+
+
+
+
+Blunk, et al.               Standards Track                    [Page 10]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+   Attribute  Value                                     Type
+   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.
+
+
+
+
+
+
+
+Blunk, et al.               Standards Track                    [Page 11]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+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].
+
+
+
+
+
+Blunk, et al.               Standards Track                    [Page 12]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+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.
+
+
+
+
+
+
+
+Blunk, et al.               Standards Track                    [Page 13]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al.               Standards Track                    [Page 14]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al.               Standards Track                    [Page 15]
+
+RFC 4012                         RPSLng                       March 2005
+
+
+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.
+
+
+
+
+
+
+
+Blunk, et al.               Standards Track                    [Page 16]
+