idnits 2.17.1 draft-blunk-rpslng-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 728. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 712. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 718. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 734), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 14 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- The draft header indicates that this document updates RFC2725, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2622, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 372 has weird spacing: '...-routes lis...' == Line 409 has weird spacing: '...members list ...' == Line 498 has weird spacing: '...ns> or opti...' == Line 499 has weird spacing: '...ns> or mult...' == Line 515 has weird spacing: '...members list ...' == (2 more instances...) (Using the creation date from RFC2622, updated by this document, for RFC5378 checks: 1998-11-19) (Using the creation date from RFC2725, updated by this document, for RFC5378 checks: 1998-03-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 23, 2004) is 7217 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ATOMIC' on line 364 ** Obsolete normative reference: RFC 3513 (ref. '3') (Obsoleted by RFC 4291) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Blunk 3 Internet-Draft Merit Network 4 Updates: 2622, 2725 (if approved) J. Damas 5 Expires: January 21, 2005 Internet Software Consortium 6 F. Parent 7 Viagenie 8 A. Robachevsky 9 RIPE NCC 10 July 23, 2004 12 Routing Policy Specification Language next generation (RPSLng) 13 draft-blunk-rpslng-08.txt 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 or will be disclosed, and any of which I become aware will be 20 disclosed, in accordance with RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 21, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 This memo presents a new set of simple extensions to the Routing 47 Policy Specification Language (RPSL) enabling the language to also 48 document routing policies for the IPv6 and multicast address families 49 currently used in the Internet. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Specifying routing policy for different address families . . . 4 55 2.1 Ambiguity Resolution . . . . . . . . . . . . . . . . . . . 4 56 2.2 The afi dictionary attribute . . . . . . . . . . . . . . . 4 57 2.3 RPSL dictionary extensions . . . . . . . . . . . . . . . . 5 58 2.4 IPv6 RPSL types . . . . . . . . . . . . . . . . . . . . . 5 59 2.5 mp-import, mp-export, and mp-default . . . . . . . . . . . 5 60 2.5.1 . . . . . . . . . . . . . . . . . . . . . 7 61 2.5.2 . . . . . . . . . . . . . . . . . . . . . 7 62 2.5.3 Policy examples . . . . . . . . . . . . . . . . . . . 8 63 3. route6 Class . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4. Updates to existing Classes to support the extensions . . . . 10 65 4.1 as-set Class . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.2 route-set Class . . . . . . . . . . . . . . . . . . . . . 10 67 4.3 filter-set Class . . . . . . . . . . . . . . . . . . . . . 10 68 4.4 peering-set Class . . . . . . . . . . . . . . . . . . . . 11 69 4.5 inet-rtr Class . . . . . . . . . . . . . . . . . . . . . . 11 70 4.6 rtr-set Class . . . . . . . . . . . . . . . . . . . . . . 12 71 5. RFC 2725 extensions . . . . . . . . . . . . . . . . . . . . . 13 72 5.1 Authorization model for route6 Objects . . . . . . . . . . 14 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 77 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 79 Intellectual Property and Copyright Statements . . . . . . . . 19 81 1. Introduction 83 RFC 2622 [1] defines the RPSL language for the IPv4 unicast routing 84 protocols and a series of guidelines for extending the RPSL language 85 itself. Additionally, security extensions to the RPSL language are 86 specified in RFC 2725 [2]. 88 This document proposes to extend RPSL according to the following 89 goals and requirements: 90 o Provide RPSL extensibility in the dimension of address families. 91 Specifically, to allow users to document routing policy for IPv6 92 and multicast. 93 o Extensions should be backward compatible with minimal impact on 94 existing tools and processes, following Section 10 of RFC 2622 [1] 95 for guidelines on extending RPSL. 96 o Maintain clarity and non-ambiguity: RPSL information is used by 97 humans in addition to software tools. 98 o Minimize duplication of information, particularly when routing 99 policies for different address families are the same. 101 The addition of IPv6 and multicast support to RPSL leads to four 102 distinct routing policies that need to be distinguished in this 103 specification, namely, (IPv4 {unicast|multicast}, IPv6 104 {unicast|multicast}). 106 2. Specifying routing policy for different address families 108 Routing policy is currently specified in the aut-num class using 109 "import:", "export:", and "default:" attributes. Sometimes it is 110 important to distinguish policy for different address families, as 111 well as a unicast routing policy from a multicast one. 113 While the syntax of the existing import, export, and default 114 attributes could be extended, this would present backward 115 compatibility issues and could undermine clarity in the expressions. 117 Keeping this in mind, the "import:", "export:", and "default:" 118 attributes implicitly specify IPv4 unicast policy and remain as 119 defined previously in RPSL, and new multi-protocol (prefixed with the 120 string "mp-") attributes are introduced. These new "mp-" attributes 121 will be described below. 123 2.1 Ambiguity Resolution 125 It is possible that the same peering can be covered by more than one 126 multi-protocol policy attribute or by a combination of multi-protocol 127 policy attributes (when specifying IPv4 unicast policy) and the 128 previously defined IPv4 unicast policy attributes. In these cases, 129 implementations should follow the specification-order rule as defined 130 in Section 6.4 of RFC 2622 [1]. Namely, to break the ambiguity, the 131 action corresponding to the first peering specification is used. 133 2.2 The afi dictionary attribute 135 In this section we introduce a new dictionary attribute: 137 Address Family Identifier, , is an RPSL list of address families 138 for which a given routing policy expression should be evaluated. 139 is optional within the new multi-protocol attributes introduced 140 in the aut-num class. A pseudo identifier named "any" is defined to 141 allow for more compact policy expressions with converged routing 142 policy. 144 The possible values for are: 145 ipv4.unicast 146 ipv4.multicast 147 ipv4 (equivalent to ipv4.unicast, ipv4.multicast) 148 ipv6.unicast 149 ipv6.multicast 150 ipv6 (equivalent to ipv6.unicast, ipv6.multicast) 151 any (equivalent to ipv4, ipv6) 152 any.unicast (equivalent to ipv4.unicast, ipv6.unicast) 153 any.multicast (equivalent to ipv4.multicast, ipv6.multicast) 155 Appearance of these values in an attribute must be preceded by the 156 keyword afi. 158 An is defined as a comma separated list of one or more afi 159 values. 161 2.3 RPSL dictionary extensions 163 In order to support IPv6 addresses specified with the next-hop 164 rp-attribute, a new predefined dictionary type entitled 165 "ipv6_address" is added to the RPSL dictionary. The definition of 166 this type is taken from Section 2.2 of RFC 3513 [3]. 168 The next-hop rp-attribute is expanded in the dictionary as follows: 170 rp-attribute: # next hop router in a static route 171 next-hop 172 operator=(union ipv4_address, ipv6_address, enum[self]) 174 A new value has been added for the dictionary 175 specification: 176 MPBGP 178 MPBGP is understood to be BGP4 with multi-protocol extensions (often 179 referred to as BGP4+). BGP4+ could not be used as the '+' character 180 is not allowed by the RPSL specification in protocol names. 182 2.4 IPv6 RPSL types 184 This document will reference three new IPv6 RPSL types, namely, 185 , , and 186 . The and 187 types are defined in Sections 2.2 and 2.3 of 188 RFC 3513 [3]. The type adds a range 189 operator to the type. The range operator is 190 defined in Section 2 of RFC 2622 [1]. 192 2.5 mp-import, mp-export, and mp-default 194 Three new policy attributes are introduced in the aut-num Class: 195 mp-import: 196 mp-export: 197 mp-default: 199 These attributes incorporate the afi (address-family) specification. 200 Note that the afi specification is optional. If no afi specification 201 is present, the policy expression is presumed to apply to all 202 protocol families, namely, ipv4.unicast, ipv4.multicast, 203 ipv6.unicast, ipv6.multicast. This is the equivalent of the afi 204 specification "afi any". The mp-import and mp-export attributes have 205 both a basic policy specification and a more powerful structured 206 policy specification. 208 The syntax for the mp-default attribute and the basic policy 209 specification of the mp-import and mp-export attributes is as 210 follows: 212 Attribute Value Type 213 mp-import [protocol ] [into ] optional, 214 [afi ] multi-valued 215 from [action ; ... ;] 216 . . . 217 from [action ; ... ;] 218 accept [;] 220 mp-export [protocol ] [into ] optional, 221 [afi ] multi-valued 222 to [action ; ... ;] 223 . . . 224 to [action ; ... ;] 225 announce [;] 227 mp-default [afi ] to optional, 228 [action ; ... ;] multi-valued 229 [networks ] 231 The mp-import and mp-export policies can be structured. As with RFC 232 2622 [1], structured policies are recommended only to advanced RPSL 233 users. The mp-import structured policy syntax is defined below. 234 Please note the semicolon at the end of an is 235 mandatory for structured policy expressions, while being optional on 236 non-structured policy expressions. The mp-export structured policy 237 syntax is expressed symmetrically to the mp-import attribute. The 238 structured syntax allows exceptions and refinements to policies by 239 use of the "except" and "refine" keywords. Further, the exceptions 240 and refinements may specify an optional "afi" list to restrict the 241 policy expression to particular address families. 243 Note that the definition allows subsequent or "cascading" refinements 244 and exceptions. RFC 2622 [1] incorrectly refers to these as "nested" 245 expressions. However, the syntax does not allow true nested 246 expressions. 248 ::= 249 from [action ; ... ;] 250 . . . 251 from [action ; ... ;] 252 accept ; 254 :: = import-factor | 255 { 256 257 . . . 258 259 } 261 ::= | 262 EXCEPT | 263 REFINE 265 ::= [afi ] 267 mp-import: [protocol ] [into ] 268 270 2.5.1 272 indicates the AS (and the router if present) and is 273 defined as follows: 275 ::= [] 276 [at ] | 278 where is an expression over AS numbers and AS sets 279 using operators AND, OR, and EXCEPT, and is an 280 expression over router ipv4-addresses or ipv6-addresses, inet-rtr 281 names, and rtr-set names using operators AND, OR, and EXCEPT. The 282 binary "EXCEPT" operator is the set subtraction operator and has the 283 same precedence as the operator AND (it is semantically equivalent to 284 "AND NOT" combination). That is "(AS65001 OR AS65002) EXCEPT 285 AS65002" equals "AS65001". 287 2.5.2 289 The policy filter expression is derived from the RPSL 290 policy filter expression defined in section 5.4 of RFC 2622 291 [1]. extends the expression to allow the 292 specification of IPv6 prefixes and prefix ranges. In particular, an 293 Address-Prefix Set expression in an expression may 294 include both IPv4 and IPv6 prefixes or prefix ranges. is 295 otherwise identical to the RPSL expression. Address-Prefix 296 Sets are enclosed in braces '{' and '}'. The policy filter matches 297 the set of routes whose destination address-prefix is in the set. 298 For example: 300 { 192.0.2.0/24, 2001:0DB8::/32 } 301 { 2001:0DB8:0100::/48^+, 2001:0DB8:0200::/48^64 } 303 2.5.3 Policy examples 305 The address family may be specified in subsequent refine or except 306 policy expression's, and is valid only within the policy expression 307 that contains it. 309 Therefore in the example: 311 aut-num: AS65534 312 mp-import: afi any.unicast from AS65001 accept as-foo; 313 except afi any.unicast { 314 from AS65002 accept AS65226; 315 } except afi ipv6.unicast { 316 from AS65003 accept {2001:0DB8::/32}; 317 } 319 the last "except" is evaluated only for the IPv6 unicast address 320 family, while other import-expressions are evaluated for both the 321 IPv6 and IPv4 unicast address families. 323 The evaluation of a policy expression is done by evaluating all of 324 its components. Evaluation of peering-sets and filter-sets is 325 constrained by the address family. Such constraints may result in a 326 "NOT ANY" or invalid depending on implicit 327 or explicit definitions of the address family in the set. Conflicts 328 with explicit or implicit declarations are resolved at runtime, that 329 is, during the evaluation of a policy expression. An RPSL evaluation 330 implementation may wish to issue a warning in the case of a "NOT ANY" 331 . The following mp-import policy contains an example of 332 an that should be evaluated as "NOT ANY". 334 aut-num: AS65002 335 mp-import: afi ipv6.unicast from AS65001 accept {192.0.2.0/24} 337 3. route6 Class 339 The route6 class is the IPv6 equivalent of the route class. As with 340 the route class, the class key for the route6 class is specified by 341 the route6 and origin attribute pair. Other than the route6 342 attribute, the route6 class shares the same attribute names with the 343 route class. While the attribute names remain identical, the inject, 344 components, exports-comps, holes, and mnt-routes attributes must 345 specify IPv6 prefixes and addresses rather than IPv4 prefixes and 346 addresses. This requirement is reflected by the specification of 347 , , and 348 below. has been previously defined. 349 is related to as defined above in Section 350 2.5.2 with the exception that only types are 351 permitted. Similarly, is related to 352 as defined above in Section 2.5.1 with the 353 exception that only types are permitted. 355 Attribute Value Type 356 route6 mandatory, class key, 357 single-valued 358 origin mandatory, class key, 359 single-valued 360 member-of list of optional, multi-valued 361 inject [at ] ... optional, multi-valued 362 [action ] 363 [upon ] 364 components [ATOMIC] [[] optional, single-valued 365 [protocol ...]] 366 aggr-bndry optional, single-valued 367 aggr-mtd inbound or outbound optional, single-valued 368 [] 369 export-comps optional, single-valued 370 holes list of optional, multi-valued 371 mnt-lower list of optional, multi-valued 372 mnt-routes list of optional, multi-valued 373 [{list of } or ANY] 375 Example: 377 route6: 2001:0DB8::/32 378 origin: AS65001 380 4. Updates to existing Classes to support the extensions 382 4.1 as-set Class 384 The as-set class defines a set of Autonomous Systems (AS), specified 385 either directly by listing them in the members attribute, or 386 indirectly by referring to another as-sets or using the mbrs-by-ref 387 facility. More importantly, "In a context that expects a route set 388 (e.g. members attribute of the route-set class), [...] an as-set 389 AS-X defines the set of routes that are originated by the ASes in 390 AS-X.", (section 5.3 of RFC 2622 [1]). 392 The as-set class is therefore used to collect a set of route 393 prefixes, which may be restricted to a specific address family. 395 The existing as-set class does not need any modifications. The 396 evaluation of the class must be filtered to obtain prefixes belonging 397 to a particular address family using the traditional filtering 398 mechanism in use in Internet Routing Registry (IRR) systems today. 400 4.2 route-set Class 402 This class is used to specify a set of route prefixes. 404 A new attribute "mp-members:" is defined for this class. This 405 attributes allow the specification of IPv4 or IPv6 406 address-prefix-ranges. 408 Attribute Value Type 409 mp-members list of ( optional, multi-valued 410 or 411 or 412 or ) 414 Example: 416 route-set: rs-foo 417 mp-members: rs-bar 418 mp-members: 2001:0DB8::/32 # v6 member 419 mp-members: 192.0.2.0/24 # v4 member 421 4.3 filter-set Class 423 The new "mp-filter:" attribute defines the set's policy filter. A 424 policy filter is a logical expression which when applied to a set of 425 routes returns a subset of these routes. The relevant parts of the 426 updated filter-set class are shown below: 428 Attribute Value Type 429 filter-set mandatory, single-valued, class key 430 filter optional, single-valued 431 mp-filter optional, single-valued 432 ... 434 Where is defined above in Section 2.5.2. While the 435 "filter:" and "mp-filter:" attributes are of type "optional", a 436 filter-set must contain one of these two attributes. Implementations 437 should reject instances where both attributes are defined in an 438 object as the interpretation of such a filter-set is undefined. 440 4.4 peering-set Class 442 The peering set class is updated with a "mp-peering:" attribute. 444 Attribute Value Type 445 peering-set mandatory, single-valued, class key 446 peering optional, multi-valued 447 mp-peering optional, multi-valued 448 ... 450 Example: 452 peering-set: prng-ebgp-peers 453 mp-peering: AS65002 2001:0DB8::1 at 2001:0DB8::2 455 With defined as above in Section 2.5.1. While the 456 "peering:" and "mp-peering:" attributes are of type "optional", a 457 peering-set must contain at least one of these two attributes. 459 4.5 inet-rtr Class 461 Two new attributes are introduced to the inet-rtr class -- 462 "interface:" which allows the definition of generic interfaces, 463 including the information previously contained in the "ifaddr:" 464 attribute, as well as support for tunnel definitions. And, 465 "mp-peer:", which includes and extends the functionality of the 466 existing "peer:" attribute. The syntax definition for the 467 "interface:" attribute follows. 469 Attribute Value Type 470 interface or optional, multi-valued 471 masklen 472 [action ] 473 [tunnel ,] 475 The syntax allows native IPv4 and IPv6 interface definitions as well 476 as the definition of tunnels as virtual interfaces. Without the 477 optional tunnel definition, this attribute allows the same 478 functionality as the "ifaddr:" attribute but extends it to allow IPv6 479 addresses. 481 In the case of the interface being a tunnel, the syntax is as 482 follows: 484 indicates the IPv4 or IPv6 address of the 485 remote endpoint of the tunnel. The address family must match that of 486 the local endpoint. denotes the encapsulation used 487 in the tunnel and is one of {GRE,IPinIP} (note the outer and inner IP 488 protocol versions can be deduced from the interface context -- for 489 example, IPv6-in-IPv4 encapsulation is just IPinIP). Routing 490 policies for these routers should be described in the appropriate 491 classes (e.g. aut-num). 493 The "mp-peer:" attribute is defined below. The difference between 494 this attribute and the "peer:" attribute is the inclusion of support 495 for IPv6 addresses. 497 Attribute Value Type 498 mp-peer or optional, 499 or multi-valued 500 or 501 or 502 504 where is a protocol name, and is a comma 505 separated list of peering options for as provided in the 506 RPSL dictionary. 508 4.6 rtr-set Class 510 The rtr-set class is extended with a new attribute, "mp-members:". 511 This attribute extends the original "members:" attribute by allowing 512 the specification of IPv6 addresses. It is defined as follows 514 Attribute Value Type 515 mp-members list of ( or optional, multi-valued 516 or 517 or 518 ) 520 5. RFC 2725 extensions 522 RFC 2725 [2] introduces an authorization model to address the 523 integrity of policy expressed in routing registries. In particular, 524 two new attributes were defined to support this authorization model, 525 namely, the "mnt-routes" and "mnt-lower" attributes. 527 In RPSLng, these attributes are extended to the route6 and inet6num 528 (described below) classes. Further, the syntax of the existing 529 mnt-routes attribute is modified to allow the optional specification 530 of IPv6 prefix range lists when present in inet6num, route6, and 531 aut-num class objects. This optional list of prefix ranges is a 532 comma-separated list enclosed in curly braces. In the aut-num class, 533 the IPv6 prefix ranges may be mixed with IPv4 prefix ranges. The 534 keyword "ANY" may also be used instead of prefix ranges. In the case 535 of inet6num and route6 objects, "ANY" refers to all more specifics of 536 the prefix in the class key field. For the aut-num class, "ANY" 537 literally means any prefix. The default when no additional set items 538 are specified is "ANY". An abbreviated definition of the aut-num 539 class with the updated syntax for the mnt-routes attribute is 540 presented below. 542 Attribute Value Type 543 aut-num mandatory, class key, 544 single-valued 545 mnt-routes list of optional, multi-valued 546 [{list of ( or 547 )} or ANY] 548 ... 550 The following is an example of mnt-routes usage. This example 551 authorizes MAINT-65001 to create route6 objects with an origin AS of 552 65002 for IPv6 address prefixes within the 2001:0DB8::/32^+ range, 553 and route objects with origin AS 65002 for IPv4 prefixes within the 554 192.0.2.0/24^+ range. 556 aut-num: AS65002 557 mnt-routes: MAINT-AS65001 {2001:0DB8::/32^+, 192.0.2.0/24^+} 559 Note, the inclusion of IPv6 prefix ranges within a mnt-routes 560 attribute in an aut-num object may conflict with existing 561 implementations of RPSL which support only IPv4 prefix ranges. 562 However, given the perceived lack of implementation of this optional 563 prefix range list, it was considered acceptable to extend the 564 existing definition of the mnt-routes attribute in the aut-num class 565 rather than creating a new attribute type. 567 Attribute Value Type 568 inet6num mandatory, single-valued, 569 class key 570 netname mandatory, single-valued 571 descr mandatory, multi-valued 572 country mandatory, multi-valued 573 admin-c mandatory, multi-valued 574 tech-c mandatory, multi-valued 575 remarks optional, multi-valued 576 notify optional, multi-valued 577 mnt-lower list of optional, multi-valued 578 mnt-routes list of optional, multi-valued 579 [{list of } or ANY] 580 mnt-by list of mandatory, multi-valued 581 changed mandatory, multi-valued 582 source mandatory, single-valued 584 The must be a valid two-letter ISO 3166 country code 585 identifier. is a symbolic name for the specified IPv6 586 address space. It does not have a restriction on RPSL reserved 587 prefixes. These definitions are taken from the RIPE Database 588 Reference Manual [4]. 590 5.1 Authorization model for route6 Objects 592 Deletion and update of a route6 object is not different from other 593 objects, as defined in RFC 2725 [2]. Creation rules of a route6 594 object is replicated here from the corresponding rules for route 595 object in RFC 2725 [2] section 9.9. 597 When adding a route6 object, the submission must satisfy two 598 authentication criteria. It must match the authentication specified 599 in the aut-num object and the authentication specified in either a 600 route6 object or if no applicable route6 object is found, then an 601 inet6num object. 603 An addition is submitted with an AS number and IPv6 prefix as its 604 key. If the aut-num object does not exist on a route6 to add, then 605 the addition is rejected. If the aut-num exists then the submission 606 is checked against the applicable maintainers. A search is then done 607 for the prefix first looking for an exact match. If the search for 608 an exact match fails, a search is made for the longest prefix match 609 that is less specific than the prefix specified. If this search 610 succeeds it will return one or more route6 objects. The submission 611 must match an applicable maintainer in at least one of these route6 612 objects for the addition to succeed. If the search for a route6 613 object fails, then a search is performed for an inet6num object that 614 exactly matches the prefix or for the most specific inet6num that is 615 less specific than the route6 object submission. 617 Having found the aut-num and either a list of route6 objects or an 618 inet6num, the authorization is taken from these objects. The 619 applicable maintainer object is any referenced by the mnt-routes 620 attributes. If one or more mnt-routes attributes are present in an 621 object, the mnt-by or mnt-lower attributes are not considered. In 622 the absence of a mnt-routes attribute in a given object, then first 623 mnt-lower attributes are used (only in the case the given object is 624 inet6num object and it is less specific than the route6 object to be 625 added), and if no applicable mnt-lower attribute is found, then the 626 mnt-by attributes are used for that object. The authentication must 627 match one of the authorization in each of the two objects. 629 6. Security Considerations 631 This document describes extensions to RFC 2622 [1] and RFC 2725 [2]. 632 The extensions address the limitations of the aforementioned 633 documents with respect to IPv6 and multicast. The extensions do not 634 introduce any new security functionality or threats. 636 While the extensions introduce no additional security threats, it 637 should be noted that the original RFC 2622 [1] RPSL standard included 638 several weak and/or vulnerable authentication mechanisms. First, the 639 "MAIL-FROM" scheme, which can be easily defeated via source email 640 address spoofing. Secondly, the "CRYPT-PW" scheme, which is subject 641 to dictionary attacks and password sniffing if RPSL objects are 642 submitted via unencrypted channels such as email. And finally, the 643 "NONE" mechanism, which offers no protection for objects. 645 7. Acknowledgments 647 The authors wish to thank all the people who have contributed to this 648 document through numerous discussions. 650 Particularly Ekaterina Petrusha for highly valuable discussions and 651 suggestions. Shane Kerr, Engin Gunduz, Mark Blanchet and David 652 Kessens participated constructively in many discussions. Finally, 653 Cengiz Alaettinoglu who is still the reference in all things RPSL. 655 8. References 657 8.1 Normative References 659 [1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 660 Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing 661 Policy Specification Language (RPSL)", RFC 2622, June 1999. 663 [2] Villamizar, C., Alaettinoglu, C., Meyer, D. and S. Murphy, 664 "Routing Policy System Security", RFC 2725, December 1999. 666 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 667 Addressing Architecture", RFC 3513, April 2003. 669 8.2 Informative References 671 [4] Damas, J. and A. Robachevsky, "RIPE Database Reference Manual", 672 August 2002. 674 Authors' Addresses 676 Larry Blunk 677 Merit Network 679 EMail: ljb@merit.edu 681 Joao Damas 682 Internet Software Consortium 684 EMail: joao@psg.com 686 Florent Parent 687 Viagenie 689 EMail: Florent.Parent@viagenie.qc.ca 691 Andrei Robachevsky 692 RIPE NCC 694 EMail: andrei@ripe.net 696 Intellectual Property Statement 698 The IETF takes no position regarding the validity or scope of any 699 Intellectual Property Rights or other rights that might be claimed to 700 pertain to the implementation or use of the technology described in 701 this document or the extent to which any license under such rights 702 might or might not be available; nor does it represent that it has 703 made any independent effort to identify any such rights. Information 704 on the procedures with respect to rights in RFC documents can be 705 found in BCP 78 and BCP 79. 707 Copies of IPR disclosures made to the IETF Secretariat and any 708 assurances of licenses to be made available, or the result of an 709 attempt made to obtain a general license or permission for the use of 710 such proprietary rights by implementers or users of this 711 specification can be obtained from the IETF on-line IPR repository at 712 http://www.ietf.org/ipr. 714 The IETF invites any interested party to bring to its attention any 715 copyrights, patents or patent applications, or other proprietary 716 rights that may cover technology that may be required to implement 717 this standard. Please address the information to the IETF at 718 ietf-ipr@ietf.org. 720 Disclaimer of Validity 722 This document and the information contained herein are provided on an 723 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 724 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 725 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 726 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 727 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 728 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 730 Copyright Statement 732 Copyright (C) The Internet Society (2004). This document is subject 733 to the rights, licenses and restrictions contained in BCP 78, and 734 except as set forth therein, the authors retain all their rights. 736 Acknowledgment 738 Funding for the RFC Editor function is currently provided by the 739 Internet Society.