1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Network Working Group L. Blunk
Request for Comments: 4012 Merit Network
Updates: <a href="./rfc2725">2725</a>, <a href="./rfc2622">2622</a> J. Damas
Category: Standards Track Internet Systems Consortium
F. Parent
Hexago
A. Robachevsky
RIPE NCC
March 2005
<span class="h1">Routing Policy Specification Language next generation (RPSLng)</span>
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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Specifying routing policy for different address families . . . <a href="#page-2">2</a>
<a href="#section-2.1">2.1</a>. Ambiguity Resolution . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. The afi dictionary attribute . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.3">2.3</a>. RPSL dictionary extensions . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.4">2.4</a>. IPv6 RPSL types . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.5">2.5</a>. mp-import, mp-export, and mp-default . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.5.1">2.5.1</a>. <mp-peering> . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.5.2">2.5.2</a>. <mp-filter> . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.5.3">2.5.3</a>. Policy examples . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3">3</a>. route6 Class . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4">4</a>. Updates to existing Classes to support the extensions . . . . <a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. as-set Class . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. route-set Class . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<span class="grey">Blunk, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
<a href="#section-4.3">4.3</a>. filter-set Class . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.4">4.4</a>. peering-set Class . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.5">4.5</a>. inet-rtr Class . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.6">4.6</a>. rtr-set Class . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5">5</a>. <a href="./rfc2725">RFC 2725</a> Extensions . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5.1">5.1</a>. Authorization model for route6 Objects . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
Full Copyright Statement . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<a href="./rfc2622">RFC 2622</a> [<a href="#ref-1" title=""Routing Policy Specification Language (RPSL)"">1</a>] 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 <a href="./rfc2725">RFC 2725</a> [<a href="#ref-2" title=""Routing Policy System Security"">2</a>].
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 <a href="./rfc2622#section-10">Section 10 of RFC 2622</a> [<a href="#ref-1" title=""Routing Policy Specification Language (RPSL)"">1</a>]
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}).
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Specifying Routing Policy for Different Address Families</span>
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.
<span class="grey">Blunk, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
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.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Ambiguity Resolution</span>
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 <a href="./rfc2622#section-6.4">Section 6.4 of RFC 2622</a> [<a href="#ref-1" title=""Routing Policy Specification Language (RPSL)"">1</a>]. To break the ambiguity, the action
corresponding to the first peering specification is used.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. The afi Dictionary Attribute</span>
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.
<span class="grey">Blunk, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. RPSL Dictionary Extensions</span>
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 <a href="./rfc3513#section-2.2">Section 2.2 of RFC 3513</a> [<a href="#ref-3" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">3</a>].
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.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. IPv6 RPSL Types</span>
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 <a href="#section-2.2">2.2</a> and <a href="#section-2.3">2.3</a> of <a href="./rfc3513">RFC 3513</a> [<a href="#ref-3" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">3</a>]. The <ipv6-address-
prefix-range> type adds a range operator to the <ipv6-address-prefix>
type. The range operator is defined in <a href="./rfc2622#section-2">Section 2 of RFC 2622</a> [<a href="#ref-1" title=""Routing Policy Specification Language (RPSL)"">1</a>].
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. mp-import, mp-export, and mp-default</span>
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.
<span class="grey">Blunk, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
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 <a href="./rfc2622">RFC</a>
<a href="./rfc2622">2622</a> [<a href="#ref-1" title=""Routing Policy Specification Language (RPSL)"">1</a>], 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. <a href="./rfc2622">RFC 2622</a> [<a href="#ref-1" title=""Routing Policy Specification Language (RPSL)"">1</a>] 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>
<span class="grey">Blunk, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
. . .
<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>
<span class="h4"><a class="selflink" id="section-2.5.1" href="#section-2.5.1">2.5.1</a>. <mp-peering></span>
<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".
<span class="h4"><a class="selflink" id="section-2.5.2" href="#section-2.5.2">2.5.2</a>. <mp-filter></span>
The <mp-filter> policy filter expression is derived from the RPSL
<filter> policy filter expression defined in <a href="./rfc2622#section-5.4">section 5.4 of RFC 2622</a>
[<a href="#ref-1" title=""Routing Policy Specification Language (RPSL)"">1</a>]. <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 }
<span class="grey">Blunk, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
<span class="h4"><a class="selflink" id="section-2.5.3" href="#section-2.5.3">2.5.3</a>. Policy Examples</span>
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}
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. route6 Class</span>
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 <a href="#section-2.5.2">Section 2.5.2</a>,
with the exception that only <ipv6-address-prefix> types are
<span class="grey">Blunk, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
permitted. Similarly, <ipv6-router-expression> is related to
<mp-router-expression> as defined above in <a href="#section-2.5.1">Section 2.5.1</a> 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
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Updates to Existing Classes to Support the Extensions</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. as-set Class</span>
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", (<a href="./rfc2622#section-5.3">section 5.3 of RFC 2622</a> [<a href="#ref-1" title=""Routing Policy Specification Language (RPSL)"">1</a>]).
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.
<span class="grey">Blunk, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. route-set Class</span>
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
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. filter-set Class</span>
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 <a href="#section-2.5.2">Section 2.5.2</a>. 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.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. peering-set Class</span>
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
<span class="grey">Blunk, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
Example:
peering-set: prng-ebgp-peers
mp-peering: AS65002 2001:0DB8::1 at 2001:0DB8::2
With <mp-peering> defined as above in <a href="#section-2.5.1">Section 2.5.1</a>. While the
"peering:" and "mp-peering:" attributes are of type "optional", a
peering-set must contain at least one of these two attributes.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. inet-rtr Class</span>
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.
<span class="grey">Blunk, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
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.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. rtr-set Class</span>
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>)
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. <a href="./rfc2725">RFC 2725</a> Extensions</span>
<a href="./rfc2725">RFC 2725</a> [<a href="#ref-2" title=""Routing Policy System Security"">2</a>] 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.
<span class="grey">Blunk, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
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 [<a href="#ref-4" title=""RIPE Database Reference Manual"">4</a>].
<span class="grey">Blunk, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Authorization Model for route6 Objects</span>
Deletion and update of a route6 object is not different from other
objects, as defined in <a href="./rfc2725">RFC 2725</a> [<a href="#ref-2" title=""Routing Policy System Security"">2</a>]. Creation rules of a route6
object is replicated here from the corresponding rules for route
object in <a href="./rfc2725">RFC 2725</a> [<a href="#ref-2" title=""Routing Policy System Security"">2</a>] <a href="#section-9.9">section 9.9</a>.
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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document describes extensions to <a href="./rfc2622">RFC 2622</a> [<a href="#ref-1" title=""Routing Policy Specification Language (RPSL)"">1</a>] and <a href="./rfc2725">RFC 2725</a> [<a href="#ref-2" title=""Routing Policy System Security"">2</a>].
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.
<span class="grey">Blunk, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
Although the extensions introduce no additional security threats, it
should be noted that the original <a href="./rfc2622">RFC 2622</a> [<a href="#ref-1" title=""Routing Policy Specification Language (RPSL)"">1</a>] 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.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
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.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing
Policy Specification Language (RPSL)", <a href="./rfc2622">RFC 2622</a>, June 1999.
[<a id="ref-2">2</a>] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy,
"Routing Policy System Security", <a href="./rfc2725">RFC 2725</a>, December 1999.
[<a id="ref-3">3</a>] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", <a href="./rfc3513">RFC 3513</a>, April 2003.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-4">4</a>] Damas, J. and A. Robachevsky, "RIPE Database Reference Manual",
August 2002.
<span class="grey">Blunk, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
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
<span class="grey">Blunk, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4012">RFC 4012</a> RPSLng March 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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]
</pre>
|
