- rpslng - mailman.ripe.net

Hi, i need information
by Juan Felipe Botero Vega 08 Nov '07

08 Nov '07

Hi, I am working in a common project between the UPC (University Polithecnic of Catalonia, Spain) and Heanet (Ireland's National Education and Research Network). I know this is not a RPSL forum, but i need to know something about this language. In the RFC 2622 RPSL is well defined, but i don't have clear if it is possible to use RPSL for internal routing. My question is: is it possible to use RPSL to perform the following actions: 1. Configure a router announcing it's the networks it has connected to. 2. Configure the routing protocols in each router (this question depends directly of the previous one) 3. Configure the *routing policies *inside the network (i am not referring to BGP policies but policies of access control in each router inside a network). This could be applied also to OSPF areas?? Thanks for your attention.

2 3

Fwd: Re: RPSL support for 32 bit ASN
by Henk Uijterwaal 15 Sep '06

15 Sep '06

>Date: Wed, 23 Aug 2006 11:20:53 +0200 >To: Mark Prior <mrp(a)mrp.net> >From: Henk Uijterwaal <henk(a)ripe.net> >Subject: Re: RPSL support for 32 bit ASN >Cc: rpslnp(a)ripe.net, asn32(a)ripe.net, ggm(a)apnic.net > >At 15:08 18/08/2006, Mark Prior wrote: > >>Is it worth doing another update to RPSL to include this > >This would certainly help us a lot (we can point to a document when >we update our tools), so ... > >... I spent a morning writing essentially a 1 page document just to >update this and submitted it as an individual submission ID, >draft-uijterwaal-rpsl-4byteas-ext-00.txt. To appear in the ID >repository soon. > >Henk > >------------------------------------------------------------------------------ >Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net >RIPE Network Coordination Centre http://www.amsterdamned.org/~henk >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 >The Netherlands The Netherlands Mobile: +31.6.55861746 >------------------------------------------------------------------------------ > >1160438400 + 381600 = 1160820000. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000.

6 14

Re: [asn32] Re: RPSL support for 32 bit ASN
by Denis Walker 18 Aug '06

18 Aug '06

Mark Prior wrote: > Henk Uijterwaal (RIPE NCC) wrote: > >> Question: How to adapt RPSL for this? >> >> Solutions: >> >> 1) Change the definition in RFC2622 to >> >> <as-number> An AS number x is represented as the string "AS[0-9]+ >> or AS[0-9]+.[0-9]+. (In other words, follow the Michealson draft). >> >> 2) Other? If so, what? > > > It would seem sensible to follow the draft rather than create > confusion by trying something different. Of course some implements may > not have a bounds check on the max size of an AS number. But they may consider it to be an integer and the new syntax will be x.y. cheers denis > > Is it worth doing another update to RPSL to include this and some > other low hanging fruit? > > Mark.

2 1

RPSL support for 32 bit ASN
by Henk Uijterwaal (RIPE NCC) 18 Aug '06

18 Aug '06

RPSL list, RFC2622 and 4012 say: <as-number> An AS number x is represented as the string "ASx". That is, the AS 226 is represented as AS226. This was written assuming 16 bit (0-65536) AS numbers (ASN16). There is now a draft to expand the AS number space to 32 bits (ASN32, see draft-ietf-idr-as4bytes-12.txt) as well as proposals in the various regions to start deploying those (RIPE2005-08, ARIN 2005-9, APNIC 032-v2 and others) as of January 2007. Draft draft-michaelson-4byte-as-representation-01.txt suggests that ASN are written as: <16 msb in decimal>.<16 lsb in decimal> with the first part dropped for values <65536. (In other words, the AS are labelled 0, 1, 2, .... 65534, 65535, 1.0, 1.1, 1.2 ... 1.65535, 2.0). I can imagine that people will want to use 32 bit ASN in RPSL starting 1/2007. Question: How to adapt RPSL for this? Solutions: 1) Change the definition in RFC2622 to <as-number> An AS number x is represented as the string "AS[0-9]+ or AS[0-9]+.[0-9]+. (In other words, follow the Michealson draft). 2) Other? If so, what? I guess in all cases, implementors will have to check that their implementations can deal with ASN >65535. Is there a WG where we can submit a draft with these extensions? Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------

1 0

[Question] BGP update messages
by Shih Ming Tseng 19 May '05

19 May '05

Hi all, I have some questions regarding to BGP update messages. Please take a look at attached data. These are part of the update messages that Route Views received from peer router "81.209.156.1" related to prefix "152.211.164.0/23" for a 3-minute time period. My long-term observation is that 81.209.156.1 dropped all paths to 152.211.164.0/23. My questions are: 1. Why there were so many update messages with "INCOMPLETE" tag and router 81.209.156.1 kept sending exactly the same path to Route Views. ? 2 Assuming that router 81.209.156.1 sent an update to Route Views if and only if the best route was changed. From the data, it looks that the path was exactly the same. If the assumption were correct, why 81.209.156.1 kept sending update ? 3. Damping on router 81.209.156.1 should have dropped the path. It looks like the damping had nothing to do with those update messages. Any comment is appreciated. Thank you, Ming BGP4MP|1065917214|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917214|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917242|W|81.209.156.1|13237|152.211.164.0/23 BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917362|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917363|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917363|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917364|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917364|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917364|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917364|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917364|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917365|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917365|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917365|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917366|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917366|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917367|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917367|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917367|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917368|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917368|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917368|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917369|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917369|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917370|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917370|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917370|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917370|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917371|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917371|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917372|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917372|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917372|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917373|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917373|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917373|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917373|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917374|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917374|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917374|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917374|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917385|A|81.209.156.1|13237|152.211.164.0/23|13237 1239 701 816|INCOMPLETE|81.209.156.1|0|0|13237:44295|NAG|| BGP4MP|1065917385|W|81.209.156.1|13237|152.211.164.0/23

1 0

RFC 4012 is now out
by Larry J. Blunk 18 Mar '05

18 Mar '05

I tidied up a few last bits with the RFC-Editor at the IETF meeting and RFC 4012 is now official. Thanks to everyone who contributed and commented on this document! -Larry http://www.ietf.org/rfc/rfc4012.txt

1 0

[Fwd: authors 48 hours: RFC 4012 <draft-blunk-rpslng-08.txt> NOW AVAILABLE]
by Larry Blunk 17 Feb '05

17 Feb '05

RFC4012 is about to be published. I believe Joao and Florent wanted their email addresses updated. Any other corrections? Speak now or forever hold your peace! -Larry

1 0

IRRtoolset 4.8.2 and RPSLng
by Dimitrios Kalogeras 15 Feb '05

15 Feb '05

Hi to all of you, I apologize for the cross posting but I believe this is of interest to all of you. We have noticed some problems with the IRRtoolset regarding the interpretation of RPSLng from RtConfig. The command used for Rtconfig is : RtConfig -h whois.ripe.net -p 43 -protocol ripe -cisco_use_prefix_lists A small template used for RtConfig was : @RtConfig set cisco_map_first_no = 10 @RtConfig set cisco_map_increment_by = 10 @RtConfig set cisco_max_preference = 220 ! Parameters @RtConfig set cisco_prefix_acl_no = 130 @RtConfig set cisco_aspath_acl_no = 130 @RtConfig set cisco_pktfilter_acl_no = 130 @RtConfig set cisco_community_acl_no = 130 @RtConfig set cisco_access_list_no = 130 ! ***** Specify each peer's incoming filter **** ! GEANT @RtConfig set cisco_map_name = "bgp-geant-%d-%d-in" @RtConfig import AS5408 195.251.27.255 AS20965 62.40.103.57 @RtConfig set cisco_map_name = "bgp-geant-%d-%d-out" @RtConfig export AS5408 195.251.27.255 AS20965 62.40.103.57 @RtConfig set cisco_map_name = "bgp-geant-bkp-%d-%d-in" @RtConfig import AS5408 195.251.27.255 AS20965 62.40.103.201 @RtConfig set cisco_map_name = "bgp-geant-bkp-%d-%d-out" @RtConfig export AS5408 195.251.27.255 AS20965 62.40.103.201 Problems: a) In lines with mp-import and afi ipv4.unicast there is error generation although the RIPE RPSLng accepts the object !!! In some cases if we download the object and execute the RtConfig -h whois.ripe.net -p 43 -protocol ripe -cisco_use_prefix_lists -f < saved object there is no problem !!! b) When we use the switch -cisco_eliminate_dup_map_parts the result is wrong when the policy has multiple address_families defined. c) It is not possible to generate route-maps when the template have IPv6 address like " @RtConfig export AS5408 2001:648:2FFF:1:: AS20965 2001:798:2017:10AA::1 if in the RIPE as object we have defined our on IPv6 attachment point. Instead to in order to generate IPv6 route maps we define @RtConfig export AS5408 195.251.27.255 AS20965 2001:798:2017:10AA::1 int the RtConfig templates !!! This results in Ipv6 route-maps generated !! d) The RPSLng robot of RIPE is broken. We intentionally provide a wrong object and the RIPE robot passed it without a problem !!! In our definition .... mp-import: # GRNET Clients ------------------------------------------- # Import Policy: # Accept all routes that: # (a) has the appropriate AS path and # (b) originates from the client (or someone behind the client) # For these routes, according to the advertised communities: # (i) set the appropriate local preference and # (ii) prepend #--------------------------------------------------------------------- afi any from prng-as5408-grnet-clients accept (PeerAS OR PeerAS:AS-TO-GRNET) AND <^PeerAS+PeerAS:AS-TO-GRNET*$>; REFINE { from AS-ANY action pref=100; accept community.contains(5408:120); from AS-ANY action pref=110; accept community.contains(5408:110); from AS-ANY action pref=111; accept community.contains(5408:109); from AS-ANY action pref=100; accept ANY; } REFINE { from AS-ANY action aspath.prepend(AS5408,AS5408,AS5408,AS5408,AS5408); accept community.contains(5408:2005); from AS-ANY action aspath.prepend(AS5408,AS5408,AS5408); accept community.contains(5408:2003); from AS-ANY accept ANY; } When we provided .... mp-import: # GRNET Clients ------------------------------------------- # Import Policy: # Accept all routes that: # (a) has the appropriate AS path and # (b) originates from the client (or someone behind the client) # For these routes, according to the advertised communities: # (i) set the appropriate local preference and # (ii) prepend #--------------------------------------------------------------------- afi any from prng-as5408-grnet-clients accept (PeerAS OR PeerAS:AS-TO-GRNET) AND REFINE { from AS-ANY action pref=100; accept community.contains(5408:120); from AS-ANY action pref=110; accept community.contains(5408:110); from AS-ANY action pref=111; accept community.contains(5408:109); from AS-ANY action pref=100; accept ANY; } REFINE { from AS-ANY action aspath.prepend(AS5408,AS5408,AS5408,AS5408,AS5408); accept community.contains(5408:2005); from AS-ANY action aspath.prepend(AS5408,AS5408,AS5408); accept community.contains(5408:2003); from AS-ANY accept ANY; } responded in the webupdates with no errors !!! Regards, Dimitrios .PS Our current policy is in the RIPE database is : aut-num: AS5408 as-name: GR-NET descr: Greek Research and Technology Network remarks: ############################################################## +# ROUTING POLICY FOR GRNET # +###################################################################### + + + =================================== + BGP Communities supported by GRNET: + =================================== + + + List of all BGP communites used by GRNET: + ----------------------------------------- + NO_EXPORT + NO_ADVERTISE + 5480:666 Blackhole this route (for /32 only) + 5408:120 Primary connection, choose first + 5408:110 Secondary connection, choose second + 5408:109 Trinary connection, choose third + 5408:2005 Prepend 5 times + 5408:4001 Do not announce to AIX + 5408:4005 Do not announce to GEANT + 5408:4010 Seeren Routes (export to RoEdunet) + + + + BGP communities appended/removed automatically by GRNET: + -------------------------------------------------------- + 5408:4001 is appended to all routes received by GEANT + 5408:4005 is appended to all routes received by AIX Peers + 5408:4010 is appended to all routes received by SEEREN Peers + 5408:4010 is removed from all non-Seeren routes received by GRNET + + + BGP communities available to GRNET clients: + ------------------------------------------- + 5408:120 Primary connection, choose first + 5408:110 Secondary connection, choose second + 5408:109 Trinary connection, choose third + 5480:666 Blackhole this route (for /32 only) + 5408:2005 Prepend 5 times + 5408:4001 Do not announce to AIX + 5408:4005 Do not announce to GEANT + !!! NO OTHER 5408:* SHOULD BE USED BY GRNET CLIENTS !!! + + + BGP communities available to SEEREN Peers: + ------------------------------------------ + 5480:666 Blackhole this route (for /32 only) + 5408:2005 Prepend 5 times + 5408:4001 Do not announce to AIX + 5408:4005 Do not announce to GEANT + !!! NO OTHER 5408:* SHOULD BE USED BY SEEREN Peers !!! + + + BGP communities available to AIX Peers: + ------------------------------------------ + 5408:2005 Prepend 5 times + !!! NO OTHER 5408:* SHOULD BE USED BY AIX Peers !!! + + + + +###################################################################### + remarks: === IMPORT POLICY ============================================ + mp-import: # iBGP (AS5408) ------------------------------------------- # accept all routes # (Note: Although this is not described here, # the border router with SEEREN clears 5408:4010 from iBGP) #--------------------------------------------------------------------- afi any from prng-as5408-ibgp accept ANY; mp-import: # GEANT AS20965 ------------------------------------------- # GEANT is the Internet Upstream for GRNET # Import Policy: # Accept all routes # Set Local Preference 100 for primary, 90 for backup # Append community for not announcement to AIX #--------------------------------------------------------------------- # IPv4 unicast and multicast afi ipv4 from AS20965 62.40.103.57 action pref=120; community.append(5408:4001); from AS20965 62.40.103.201 action pref=130; community.append(5408:4001); accept ANY; mp-import: # IPv6 unicast afi ipv6.unicast from AS20965 2001:798:2017:10AA::1 action pref=120; community.append(5408:4001); from AS20965 2001:798:2017:10AA::9 action pref=130; community.append(5408:4001); accept ANY; mp-import: # RoEdunet (AS2614) --------------------------------------- # RoEdunet is the Backup Upstream for SEEREN peers only! # Import Policy: # Accept all ipv4 unicast routes # Set Local Preference of RoEdunet routes to 50 #--------------------------------------------------------------------- afi ipv4.unicast from AS2614 action pref=170; accept ANY; mp-import: # OteGlobe (AS12713) -------------------------------------- # Peering for Seeren SCS VPN purposes only # Import Policy: # Only allow connection networks (62.75.33.228/27), # PE loopbacks (62.75.26.216/29) and CE loopbacks #--------------------------------------------------------------------- afi ipv4.unicast from AS12713 action pref=70; # High preference; community.append(NO_ADVERTISE); accept {62.75.33.228/27^+, 62.75.26.216/29^+, 147.91.0.112/32, 193.254.1.242/32, 194.141.252.13/32, 194.149.130.249/32}; mp-import: # Blackhole Routing for GRNET & SEEREN Clients ------------ # this command is not supported by RPSL and the RIPE database :-( # we are implementing it, though #--------------------------------------------------------------------- afi any.unicast from AS-ANY action community.append(NO_EXPORT); # next-hop = x.x.x.x; accept community.contains(5408:666) AND (PeerAS OR PeerAS:AS-TO-GRNET) AND {0.0.0.0/0^32} AND <^PeerAS+PeerAS:AS-TO-GRNET*$>; REFINE { from prng-as5408-grnet-clients accept ANY; from prng-as5408-seeren accept ANY; } mp-import: # GRNET Clients ------------------------------------------- # Import Policy: # Accept all routes that: # (a) has the appropriate AS path and # (b) originates from the client (or someone behind the client) # For these routes, according to the advertised communities: # (i) set the appropriate local preference and # (ii) prepend #--------------------------------------------------------------------- afi any from prng-as5408-grnet-clients accept (PeerAS OR PeerAS:AS-TO-GRNET) AND <^PeerAS+PeerAS:AS-TO-GRNET*$>; REFINE { from AS-ANY action pref=100; accept community.contains(5408:120); from AS-ANY action pref=110; accept community.contains(5408:110); from AS-ANY action pref=111; accept community.contains(5408:109); from AS-ANY action pref=100; accept ANY; } REFINE { from AS-ANY action aspath.prepend(AS5408,AS5408,AS5408,AS5408,AS5408); accept community.contains(5408:2005); from AS-ANY action aspath.prepend(AS5408,AS5408,AS5408); accept community.contains(5408:2003); from AS-ANY accept ANY; } mp-import: # SEEREN Peers --------------------------------------------- # Import Policy: # Accept all ipv4 unicast and ipv6 unicast routes that # (a) has the appropriate AS path and # (b) originates from the peer (or someone behind that peer) # For these routes, according to the advertised communities: # (i) set the appropriate local preference # (ii) append the community for announcement to RoEdunet and # (ii) prepend #--------------------------------------------------------------------- afi any.unicast from prng-as5408-seeren action pref=100; community.append(5408:4010); accept (PeerAS OR PeerAS:AS-TO-GRNET) AND <^PeerAS+PeerAS:AS-TO-GRNET*$>; REFINE { from AS-ANY action aspath.prepend(AS5408,AS5408,AS5408,AS5408,AS5408); accept community.contains(5408:2005); from AS-ANY action aspath.prepend(AS5408,AS5408,AS5408); accept community.contains(5408:2003); from AS-ANY accept ANY; } mp-import: # AIX Peers ------------------------------------------------ # Import Policy: # Accept all routes that # (a) has the appropriate AS path and # (b) originates from the peer (or someone behind that peer) # For these routes, according to the advertised communities: # (i) set the appropriate local preference # (ii) append the community for not announcement to Geant and # (ii) prepend #--------------------------------------------------------------------- afi ipv4 from prng-as5408-aix action pref=100; community.append(5408:4005); accept (PeerAS OR PeerAS:AS-TO-AIX) AND <^PeerAS+PeerAS:AS-TO-AIX*$>; REFINE { from AS-ANY action aspath.prepend(AS5408,AS5408,AS5408,AS5408,AS5408); accept community.contains(5408:2005); from AS-ANY action aspath.prepend(AS5408,AS5408,AS5408); accept community.contains(5408:2003); from AS-ANY accept ANY; } mp-import: # K-ROOT mirror @ AIX -------------------------------------- # Import Policy: # Accept K-Root routes and # append the community for not announcement to GEANT #--------------------------------------------------------------------- afi ipv4.unicast from AS25152 action pref=100; community.append(5408:4005); accept {193.0.14.0/24, 195.251.59.0/28} + remarks: === EXPORT POLICY ============================================ + mp-export: # iBGP (AS5408) -------------------------------------------- # Export Policy: # Do not propagate RoEdunet routes via iBGP #--------------------------------------------------------------------- afi any to prng-as5408-ibgp announce (NOT <^AS2614>); EXCEPT { to prng-as5408-ibgp-part announce NOT community.contains(5408:4001); } mp-export: # GEANT (AS20965) ------------------------------------------ # Export Policy: # Announce all routes except from those with community (5408:4005) #--------------------------------------------------------------------- afi any to AS20965 announce NOT community.contains(5408:4005); mp-export: # RoEdunet (AS2614) ---------------------------------------- # RoEdunet is the Backup Upstream for SEEREN peers only! # Export Policy: # Announce only IPv4 unicast routes with 5408:4010 community #--------------------------------------------------------------------- afi ipv4.unicast to AS2614 announce community.contains(5408:4010); mp-export: # OteGlobe (AS12713) Peering for Seeren VPN purposes ------- # Export Policy: # Only announce CE loopback #--------------------------------------------------------------------- afi ipv4.unicast to AS12713 announce {194.177.210.40/32}; mp-export: # AIX Peers ------------------------------------------------ # Export Policy: # Announce all routes except from those with community (5408:4001) #--------------------------------------------------------------------- afi ipv4.unicast to prng-as5408-aix announce NOT community.contains(5408:4001); mp-export: # GRNET Clients & Seeren Peers ----------------------------- # Export Policy: # Announce either all routes or a partial routing table #--------------------------------------------------------------------- afi any to prng-as5408-grnet-firt announce ANY; EXCEPT { to prng-as5408-grnet-part announce NOT community.contains(5408:4001); } + remarks: ############################################################## +# END OF ROUTING POLICY FOR GRNET # +###################################################################### + admin-c: GN28-RIPE tech-c: GN28-RIPE mnt-by: GRNET-NOC changed: D.Kalogeras(a)noc.ntua.gr 19990622 changed: D.Kalogeras(a)noc.ntua.gr 20031120 changed: D.Kalogeras(a)noc.ntua.gr 20031128 changed: D.Kalogeras(a)noc.ntua.gr 20031201 changed: A.Polyrakis(a)noc.ntua.gr 20031218 changed: A.Polyrakis(a)noc.ntua.gr 20041202 changed: A.Polyrakis(a)noc.ntua.gr 20050203 changed: D.Kalogeras(a)noc.ntua.gr 20050215 source: RIPE -- -- Dimitrios K. Kalogeras Electrical Engineer Ph.D. Network Manager NTUA/GR-Net Network Management Center _____________________________________ icq: 11887484 voice: +30-210-772 1863 fax: +30-210-772 1866 e-mail: D.Kalogeras(a)noc.ntua.gr pub 1024D/F2A69A72 2002-12-13 Dimitrios Kalogeras <D.Kalogeras(a)noc.ntua.gr> Key fingerprint = 64C5 646D 8D33 A3FF 14D1 66C6 5127 54CC F2A6 9A72

1 0

The release of RPSLng IRRToolSet
by Katie Petrusha 03 Aug '04

03 Aug '04

[ Apologies for multiple messages ] Dear Colleagues, The RIPE NCC is pleased to announce version 4.8.2 release of IRRToolSet. RPSLng is an effort to extend RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used on the Internet. IRRToolSet implements the Internet Draft Document draft-blunk-rpslng-07 (ftp://ftp.ietf.org/internet-drafts/draft-blunk-rpslng-07.txt) The release contains peval, rpslcheck and RtConfig that support RPSLng. The software can be compiled using GCC-3.x, and also includes numerous contributed patches, bug fixes and changes related to the new draft. Please note that this will be the last release of IRRToolSet made by the RIPE NCC. Further IRRToolSet will be maintained by ISC (Internet Systems Consortium). More details regarding the migration will follow soon. The source code release and binary packages can be downloaded from: ftp://ftp.ripe.net/tools/IRRToolSet You can also check the IRRToolSet project page: http://www.ripe.net/db/irrtoolset Thanks to everyone who contributed the patches and bug fixes. Please contact <irrtoolset(a)ripe.net> for any comments. -- Best regards, Katie Petrusha RIPE NCC

1 0

Re:
by Jhaas 20 Jul '04

20 Jul '04

1 0

Prototype of RPSLng Whois Server
by DB Role Account 28 Jun '04

28 Jun '04

[ Apologies for duplicate messages ] Dear Colleagues, The RIPE NCC Software Engineering Group provides an RPSLng prototype whois server on host rpslng.ripe.net, port 53001. RPSLng is an effort to extend the RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. The prototype RPSLng whois server has been updated to implement draft-blunk-rpslng-05.txt the latest Internet Draft of the RPSLng effort: ftp://ftp.ripe.net/internet-drafts/draft-blunk-rpslng-05.txt One discrepancy between the draft and the prototype server is that, the optional list of prefixes between the '{' and '}' in the "mnt-routes:" attributes of AUT-NUM and ROUTE6 objects has not been implemented. This functionality will be added later. The prototype database contains a snapshot of the RIPE Whois Database. It can be updated by sending mails to <rpslng-auto(a)ripe.net>. Please note, this database is only for test purposes and updates performed on it will NOT be reflected on the production RIPE Whois Database. The prototype RPSLng server was put into production in May 2003. We have refreshed the contents of the prototype database using a recent snapshot from the live RIPE Whois Database. We have kept the ROUTE6 objects, as well as AUT-NUM objects with "mp-*" attributes, while refreshing the contents. Up-to-date details can be found at: http://www.ripe.net/db/rpslng Regards, Shane Kerr Software Engineering Department Manager RIPE NCC

1 0

draft-blunk-rpslng-05.txt has been submitted
by Larry J. Blunk 31 May '04

31 May '04

The draft is available at www.radb.net/rpslng-05.html. The structured syntax has been updated to reflect comments by Cengiz and Mark. Note that the optional afi field is now outside the brackets in refine and except expressions. I believe this is simpler and more intuitive. We may wish to simplify further and only allow an initial afi specification on policy expressions (similar to the optional protocol fields). However, I don't have a strong opinion on this. -Larry

7 7

RPSLng and nested refine/except expressions
by Larry J. Blunk 12 May '04

12 May '04

In the -04 version of the RPSLng draft, the structured policy syntax was updated to allow nested refines and excepts in policy expressions. I.e. refine { <expression> refine { <expression> } } Examples of such expressions are given both RFC2622 and the RPSLng draft. However, the original RFC2622 syntax did not actually allow such expressions. However, in the process of implementing and running the syntax check on existing objects, I have found examples of the following: refine { <expression> } refine { <expression> } See, for example, AS7574 in the RADB. Unfortunately, such expressions are invalid in the lastest RPSLng draft. Are such expressions semantically identical to nested refines/excepts? Should both this form and the nested form be allowed. I have come up with a minor modification to the -04 syntax that would allow both, but I'm not sure if it is a good idea or not. -Larry

3 3

rpslcheck utility vs rpslng-auto@ripe.net
by Dimitrios Kalogeras 04 May '04

04 May '04

Hi to all of you, I am using the rpslcheck utility from the IRRToolSet 4.8.1 distribution before submiting them to the rpslng-auto(a)ripe.net. Although the rpslcheck tool provides error free result, the backend system from ripe responses with error ? Do you know if there is any differences between them ? Thanks, Dimitrios .PS I suppose there is an error in the page http://www.ripe.net/db/rpslng/ . The reason is that although it is stated that there is an RPSLng prototype Whois server on host rpslng.ripe.net, port 53001 the response from this server leads me to apnic. is this correct ? ajax# whois -h rpslng.ripe.net -p 53001 as5408 % [whois.apnic.net node-1] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html %ERROR:101: no entries found % % No entries found in the selected source(s). % [whois.apnic.net node-2] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html %ERROR:101: no entries found % % No entries found in the selected source(s). -- -- Dimitrios K. Kalogeras Electrical Engineer Ph.D. Network Manager NTUA/GR-Net Network Management Center _____________________________________ icq: 11887484 voice: +30-210-772 1863 fax: +30-210-772 1866 e-mail: D.Kalogeras(a)noc.ntua.gr pub 1024D/F2A69A72 2002-12-13 Dimitrios Kalogeras <D.Kalogeras(a)noc.ntua.gr> Key fingerprint = 64C5 646D 8D33 A3FF 14D1 66C6 5127 54CC F2A6 9A72

2 1

New RPSLng draft now up
by Larry J. Blunk 28 Apr '04

28 Apr '04

Please review http://www.ietf.org/internet-drafts/draft-blunk-rpslng-04.txt. This clarifies the structured syntax for mp-import/mp-export attributes (and the use of the "action" keyword). Some examples were also fixed to be consistent with the syntax. -Larry

1 0

RPSLng info please
by Dimitrios Kalogeras 09 Apr '04

09 Apr '04

I would like to have your opinion on the following issues. I beleive the last draft http://www.ietf.org/internet-drafts/draft-blunk-rpslng-03.txt has some serious typos. Specifically in section 2.5 the definition of EXCEPT and REFINE do not allow for nay curly bracket after the EXCEPT or REFINE . mp-import ::= [protocol <protocol-1>] [into <protocol-2>] <import-expression> <import-expression> ::= [afi <afi-list>] <import-term> accept <mp-filter> | [afi <afi-list>] <import-term> accept <mp-filter> EXCEPT <import-expression> | [afi <afi-list>] <import-term> accept <mp-filter> REFINE <import-expression> <import-term> ::= <import-factor> | { <import-factor> ... <import-factor> } <import-factor> ::= from <mp-peering> [action <action>]; While in the policy examples there are curly brackets after REFINE and EXCEPT. The second issue is with regard of the logic of REFINE and EXCEPT statements. Does the RPSLng REFINE statements refines the afi protocol list ? if yes then this is not shown in the grammar. Assume for example that I would like to express a policy like import from AS-ANY accept ANY but from AS 1 if accept community (1:3);(action xxx); but from AS 1 if accept community (1:5); action yyy); how do I express this in RPSL ng? Is this a typical usage of REFINE or EXCEPT statement ? If this is a typiical usage of EXCEPT statement it would be nice to have some kind of appendinx for porting policies from rfc2622 to RPSLng. Regards, Dimitrios -- -- Dimitrios K. Kalogeras Electrical Engineer Ph.D. Network Manager NTUA/GR-Net Network Management Center _____________________________________ icq: 11887484 voice: +30-210-772 1863 fax: +30-210-772 1866 e-mail: D.Kalogeras(a)noc.ntua.gr pub 1024D/F2A69A72 2002-12-13 Dimitrios Kalogeras <D.Kalogeras(a)noc.ntua.gr> Key fingerprint = 64C5 646D 8D33 A3FF 14D1 66C6 5127 54CC F2A6 9A72

2 1

draft-blunk-rpslng-03.txt
by Larry J. Blunk 04 Mar '04

04 Mar '04

The lastest RPSLng draft (draft-blunk-rpslng-03.txt) is now up on the IETF site. I'd like to issue an internal last call to the mailing list before taking this to the IESG for last call. Thanks, Larry

1 0

Proposed changes to aut-num policy syntax in RPSLng
by Larry J. Blunk 26 Feb '04

26 Feb '04

Andrei Robachevsky has proposed the following changes to the syntax for policy expressions in RPSLng based on feedback from the list and a desire to simplify the syntax for the case where v4/v6 and/or unicast/multicast policy are converged. 1) the absence of safi in an expression means that both unicast and multicast are defined. I.e., afi ipv4 == afi ipv4.unicast,ipv4.multicast 2) The afi specification will be optional in the mp-* attributes in the aut-num class. If no afi is specified, the policy shall be expanded to include all afi and safi types, namely -- afi ipv4.unicast,ipv4.multicast,ipv6.unicast,ipv6.multicast 3) introduce a pseudo afi with the value of "any". I.e., afi any.unicast == afi ipv4.unicast,ipv6.unicast afi any == afi ipv4.unicast,ipv6.unicast,ipv4.multicast,ipv6.multicast Looking forward to your feedback. Regards, Larry

3 3

RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)
by Wijnen, Bert (Bert) 29 Jan '04

29 Jan '04

OK, I now found that the doc did have an IETF Last Call in late August/Early Sept. So I assume that the current version has addressed all those Last Call comments. I will put it on my plate (and have recorded this in ID-tracker). Pls ping me if you do not hear about my AD review by say Jan 5th Thanks, Bert > -----Original Message----- > From: Larry J. Blunk [mailto:ljb@merit.edu] > Sent: maandag 22 december 2003 23:10 > To: Pekka Savola > Cc: Wijnen, Bert (Bert); curtis(a)fictitious.org; rpslng(a)ripe.net; > rps(a)ietf.org > Subject: RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft) > > > On Mon, 2003-12-22 at 16:29, Pekka Savola wrote: > > On Mon, 22 Dec 2003, Wijnen, Bert (Bert) wrote: > > > Yes, but I need to know what you want, Standards track or not. > > > If you want it standards track, then you need to find an AD, and > > > since RPSL was an old OPS WG, I am willing to consider it. > > > > > > If you want it to be informational, then I am not sure if I need > > > to get involved. However, if you want IETF review and an IETF > > > Last Call, then it is probably still a good idea to go > through an AD > > > (and I am willing to consider). > > > > > > Can you point me to archives where your work was discussed? > > > > Well, when the last call was made, RPSLng document was deemed for > > Proposed Standard. And I agree with this. > > > > The confusion may have come from the fact that Curtis > mentioned that > > maybe the other parts of RPSL might be progressed on the standards > > track, to DS. Then re-forming a WG would be a good idea. > > > > But I think the issue above is premature. We need to ship > this, today > > if not yesterday :-). It's really needed. Individual submission > > seems fine by me -- everyone interested is reading these lists > > anyway, it won't get any better by cranking up the formal > > structures again :-). > > Okay, this sounds good. > > Bert, the RPSLng work is documented in the list archives hosted > by the RIPE NCC at > http://www.ripe.net/ripe/mail-archives/rpslng/index.html > We've had a number of formal/informal get-togethers at RIPE and IETF > meetings. If you don't want to get involved, I will make an > individual submission. > > Regards, > Larry > >

11 15

RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)
by Wijnen, Bert (Bert) 22 Dec '03

22 Dec '03

> On Tue, 2003-12-09 at 12:01, Curtis Villamizar wrote: > > In message <1070985052.3794.5.camel(a)ablate.merit.edu>, > "Larry J. Blunk" writes: > > > The latest draft is now up on the IETF repository -- > > > http://www.ietf.org/internet-drafts/draft-blunk-rpslng-02.txt > > > > > > I've also put an HTML copy at > > > http://www.radb.net/rpslng.html > > > > > > Does anyone have any objections to going to last call again? > > > > > > -Larry > > > > > > No objections here. There were no comments since you sent out this > > revision (so far at least). > > > > For this to go standards track, it would be best if this were a WG > > document which would mean we should reopen the WG. If so, then I > > suggest that the WG move this document toward PS. If we're going to > > reopen then we should decide whether to move RPSL RFC-2622 to DS, > > recycle as PS with changes, or merge with RPSLng and recycle as PS. > > The latter (combine RPSL and RPSLng) would be more work (a > *lot* more > > work) but it has been suggested and might improve clarity. > If the WG > > just wants to make RPSLng a WG doc and then advance it as PS, the WG > > might be able to do so with very strong concensus on the > list but more > > likely would have to reopen and meet at least once, then > close again. > > If the TCPLW WG can be considered as a valid precendence then this > > shouldn't be too much trouble, but IESG requirements for WG > procedures > > have changed (and are continuing to change). > > > > Curtis > > Curtis, > I'm not sure if there is big need to push this standards track or > to merge the RPSL and RPSLng documents. At this point, we (the > RPSLng group) have been working on this document for 2 years now and I > think the consensus is to go forward without re-opening the WG. > > Since there have been no further comments I'd like to go to > last call on draft-blunk-rpslng-02. As Randy is no longer an > A-D, I assume it is up to Bert Wijnen to put this before the IESG? > Yes, but I need to know what you want, Standards track or not. If you want it standards track, then you need to find an AD, and since RPSL was an old OPS WG, I am willing to consider it. If you want it to be informational, then I am not sure if I need to get involved. However, if you want IETF review and an IETF Last Call, then it is probably still a good idea to go through an AD (and I am willing to consider). Can you point me to archives where your work was discussed? Bert > Regards, > Larry Blunk > > >

3 2

Latest RPSLng draft
by Larry J. Blunk 22 Dec '03

22 Dec '03

I forgot to add that there is also an HTML version available at www.radb.net/rpslng.html -Larry

3 5

Latest RPSLng draft -second try
by Larry J. Blunk 21 Nov '03

21 Nov '03

My first try didn't make it through because the post was too big. I've added the draft inline this time. I've enclosed the latest draft of the RPSLng spec. I've left the afi definition section as it was previously as I don't think there was consensus to change the meaning of ipv4 and ipv6 to include both unicast and multicast. Please let me know if there are any strong feelings about this. One option could be to add ipv4.any and ipv6.any types as a shorthand for ipv4.unicast,ipv4.multicast and ipv6.unicast,ipv6.multicast. However, I'm not sure if this doesn't actually make things worse by creating more clutter in the spec. I've reduced the encapsulation types for the tunnel option in the interface: attribute to just GRE and IPinIP. IPinIP was deemed sufficient since you already know the address types of the encapsulating end-points. DVMRP was dropped since the protocol/encapsulation method seems to be deprecated at this point. Should we add other encapsulation methods to this attribute? For example, LT2P, PPTP, or IPSec? Would it be useful to have an afi specification to indentify/restrict the address family types carried across the tunnel? -Larry Blunk Merit Network Working Group L. Blunk Internet-Draft Merit Network Updates: 2262, 2725 (if approved) J. Damas Expires: May 20, 2004 Internet Software Consortium F. Parent Viagenie A. Robachevsky RIPE NCC November 20, 2003 Routing Policy Specification Language next generation (RPSLng) draft-blunk-rpslng-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 20, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo presents a new set of simple extensions to the Routing Policy Specification Language (RPSL) [1] enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. Blunk, et al. Expires May 20, 2004 [Page 1] Internet-Draft RPSLng November 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specifying routing policy for different address families . . 4 2.1 Ambiguity Resolution . . . . . . . . . . . . . . . . . . . . 4 2.2 The afi dictionary attribute . . . . . . . . . . . . . . . . 4 2.3 RPSL dictionary extensions . . . . . . . . . . . . . . . . . 5 2.4 IPv6 RPSL types . . . . . . . . . . . . . . . . . . . . . . 5 2.5 mp-import, mp-export, and mp-default . . . . . . . . . . . . 5 2.5.1 <mp-peering> . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5.2 <mp-filter> . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5.3 Policy examples . . . . . . . . . . . . . . . . . . . . . . 7 3. route6 Class . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Updates to existing Classes to support the extensions . . . 10 4.1 as-set Class . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 route-set Class . . . . . . . . . . . . . . . . . . . . . . 10 4.3 filter-set Class . . . . . . . . . . . . . . . . . . . . . . 10 4.4 peering-set Class . . . . . . . . . . . . . . . . . . . . . 11 4.5 inet-rtr Class . . . . . . . . . . . . . . . . . . . . . . . 11 4.6 rtr-set Class . . . . . . . . . . . . . . . . . . . . . . . 12 5. RFC 2725 extensions . . . . . . . . . . . . . . . . . . . . 14 5.1 Authorization model for route6 Objects . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 Normative References . . . . . . . . . . . . . . . . . . . . 19 Informative References . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 21 Blunk, et al. Expires May 20, 2004 [Page 2] Internet-Draft RPSLng November 2003 1. Introduction RFC 2622 [1] defines the RPSL language for the IPv4 unicast routing protocols and 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}). Blunk, et al. Expires May 20, 2004 [Page 3] Internet-Draft RPSLng November 2003 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. While 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 remain as defined previously in RPSL, and new multi-protocol (prefixed with the string "mp-") attributes are introduced. These new "mp-" attributes will be described below. 2.1 Ambiguity Resolution It is possible that 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]. Namely, to break the ambiguity, the action corresponding to the first peering specification is used. 2.2 The afi dictionary attribute In this section we introduce 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 mandatory within the new multi-protocol attributes introduced in the aut-num class. The possible values for <afi> are: ipv4 ipv4.unicast (equivalent to ipv4) ipv4.multicast ipv6 ipv6.unicast (equivalent to ipv6) ipv6.multicast Appearance of these values in an attribute must be preceded by the keyword afi. Blunk, et al. Expires May 20, 2004 [Page 4] Internet-Draft RPSLng November 2003 An <afi-list> is defined as a comma separated list of one or more afi values. 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. The mp-import and mp-export attributes have both a basic policy specification and a more powerful structured policy specification. The syntax for the mp-default attribute and the basic policy Blunk, et al. Expires May 20, 2004 [Page 5] Internet-Draft RPSLng November 2003 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>] . . . from <mp-peering-N> [action <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>] . . . to <mp-peering-N> [action <action-N>] announce <mp-filter> mp-default afi <afi-list> to <mp-peering> optional, [action <action>] [networks <mp-filter>] multi-valued The mp-import and mp-export policies can be structured. As with RFC 2622 [1], structured policies are recommended only to advanced RPSL users. For the sake of brevity, only the mp-import structured policy syntax is defined below. The mp-export structured policy syntax is expressed in a symmetric way to the mp-import attribute. mp-import ::= [protocol <protocol-1>] [into <protocol-2>] <import-expression> <import-expression> ::= afi <afi-list> <import-term> accept <mp-filter> | afi <afi-list> <import-term> accept <mp-filter> EXCEPT <import-expression> | afi <afi-list> <import-term> accept <mp-filter> REFINE <import-expression> <import-term> ::= <import-factor> | { <import-factor> ... <import-factor> } <import-factor> ::= from <mp-peering> [action <action>]; Blunk, et al. Expires May 20, 2004 [Page 6] Internet-Draft RPSLng November 2003 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 "(AS1 OR AS2) EXCEPT AS2" equals "AS1". 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: { 198.108.0.0/16, 3ffe:ffff:240::/48 } { 3ffe:ffff:580::/48^+, 3ffe:ffff:600::/48^64 } 2.5.3 Policy examples The address family may be specified at any level of nesting of <import-expression>, and is valid only within the <import-expression> that contains it. Therefore in the example: aut-num: AS65534 mp-import: afi ipv6.unicast,ipv4 from AS65001 action pref = 1; accept as-foo except { afi ipv6.unicast,ipv4 from AS65002 action pref = 2; accept AS65226 except { afi ipv6.unicast from AS65003 action pref = 3; accept {3FFE:FFFF::/32} Blunk, et al. Expires May 20, 2004 [Page 7] Internet-Draft RPSLng November 2003 } } the last (rightmost) "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 an <import-expression> is done by evaluating all 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. An RPSL evaluation implementation may wish to issue a warning in the case of a {NOT ANY} <mp-filter>. Conflicts with explicit or implicit declarations are resolved at runtime, that is, during the evaluation of a policy expression. For example, when evaluating the following import policy: aut-num: AS65002 mp-import: afi ipv6 from AS65001 accept {193.0.0.0/22} the mp-filter should be evaluated as {NOT ANY}. A more complex example follows: aut-num: AS65002 mp-import: afi ipv6.unicast { from AS-ANY action med = 0; accept {3FFE:FFFF::/32}; } refine { afi ipv6.unicast from AS65001 at 3FFE:FFFF::1 action pref = 1; accept AS-UPSTREAM; from prng6-ebgp-peers action pref = 2; accept AS65001; } In this example, only IPv6 prefixes originated by AS65001 will be collected, and when evaluating the as-set AS-UPSTREAM, only IPv6 prefixes of the member ASes will be considered. Blunk, et al. Expires May 20, 2004 [Page 8] Internet-Draft RPSLng November 2003 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. While 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 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. Note that <ipv6-address-prefix> may be of either type ipv6.unicast or type ipv6.multicast. An IPv6 multicast address is indentified by the binary 11111111 at the start of the address. For futher reference, please see Section 2.7 of RFC 3513 [3]. 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: 3ffe:ffff:240::/48 origin: AS65001 Blunk, et al. Expires May 20, 2004 [Page 9] Internet-Draft RPSLng November 2003 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-sets 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. 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 attributes allow 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: 3FFE:FFFF::/32 # v6 member mp-members: 128.9.0.0/16 # 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 which when applied to a set of routes returns a subset of these routes. The relevant parts of the Blunk, et al. Expires May 20, 2004 [Page 10] Internet-Draft RPSLng November 2003 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 ... Example: peering-set: prng-ebgp-peers mp-peering: AS65002 3FFE:FFFF::1 at 3FFE:FFFF::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. Below is the syntax definition for the new "interface:" attribute. Blunk, et al. Expires May 20, 2004 [Page 11] Internet-Draft RPSLng November 2003 Attribute Value Type interface <ipv4-address> or <ipv6-address> optional, multi-valued masklen <mask> [action <action>] [tunnel <remote-endpoint-address>,<encapsulation>] The new 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. In the case of the interface being 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}. 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. 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:", defined as Attribute Value Type mp-members list of (<inet-rtr-name> or optional, multi-valued <rtr-set-name> or <ipv4-address> or <ipv6-address>) Blunk, et al. Expires May 20, 2004 [Page 12] Internet-Draft RPSLng November 2003 This attribute extends the original "members:" attribute by allowing the specification of IPv6 addresses. Blunk, et al. Expires May 20, 2004 [Page 13] Internet-Draft RPSLng November 2003 5. RFC 2725 extensions RFC 2725 [2] introduces an authorization model to address the integrity of policy expressed in routing registries. In particular, two new attributes were defined to support this authorization model, namely, 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" many 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". 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 3ffe:ffff::/32^+ range, and route objects with origin AS 65002 for IPv4 prefixes within the 35.42.0.0/16^+ range. aut-num: AS65002 mnt-routes: MAINT-AS65001 {3ffe:ffff::/32^+, 35.42.0.0/16^+} Note, the inclusion of IPv6 prefix ranges within a mnt-routes attribute in an aut-num object may conflict with existing implementations of RPSL which support only IPv4 prefix ranges. However, given the perceived lack of implementation of this optional prefix range list, it was considered acceptable to extend the existing definition of the mnt-routes attribute in the aut-num class rather than creating a new attribute type. Blunk, et al. Expires May 20, 2004 [Page 14] Internet-Draft RPSLng November 2003 Attribute Value Type inet6num <ipv6-address-prefix> mandatory, single-valued, class key netname <netname> mandatory, single-valued descr <free-form> mandatory, multi-valued country <country-code> mandatory, multi-valued admin-c <nic-handle> mandatory, multi-valued tech-c <nic-handle> mandatory, multi-valued remarks <free-form> optional, multi-valued notify <email-address> optional, multi-valued mnt-lower list of <mntner-name> optional, multi-valued mnt-routes list of <mntner-name> optional, multi-valued [{list of <ipv6-address-prefix-range>} or ANY] mnt-by list of <mntner-name> mandatory, multi-valued changed <email-address> <date> mandatory, multi-valued source <registry-name> mandatory, single-valued The <country-code> must be a valid two-letter ISO 3166 country code identifier. <netname> is a symbolic name for the specified IPv6 address space. It does not have a restriction on RPSL reserved prefixes. These definitions are taken from the RIPE Database Reference Manual [4]. 5.1 Authorization model for route6 Objects Deletion and update of a route6 object is not different from other objects, as defined in RFC 2725 [2]. Creation rules of a route6 object is replicated here from the corresponding rules for route object in RFC 2725 [2] section 9.9. When adding a route6 object, the submission must satisfy two authentication criteria. It must match the authentication specified in the aut-num object and the authentication specified in either a route6 object or if no applicable route6 object is found, then 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 first looking for an exact match. If the search for an exact match fails, a search is made for the longest prefix match that is 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 Blunk, et al. Expires May 20, 2004 [Page 15] Internet-Draft RPSLng November 2003 matches the prefix or for the most specific inet6num that is less specific than the route6 object submission. Having found the aut-num and either a list of route6 objects or an inet6num, 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, then first mnt-lower attributes are used (only in the case the given object is inet6num object and it is less specific than the route6 object to be added), and 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 authorization in each of the two objects. Blunk, et al. Expires May 20, 2004 [Page 16] Internet-Draft RPSLng November 2003 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. While 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. Secondly, 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. Blunk, et al. Expires May 20, 2004 [Page 17] Internet-Draft RPSLng November 2003 7. Acknowledgments 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, Mark Blanchet and David Kessens participated constructively in many discussions. Finally, Cengiz Alaettinoglu who is still the reference in all things RPSL. Blunk, et al. Expires May 20, 2004 [Page 18] Internet-Draft RPSLng November 2003 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. Blunk, et al. Expires May 20, 2004 [Page 19] Internet-Draft RPSLng November 2003 Informative References [4] Damas, J. and A. Robachevsky, "RIPE Database Reference Manual", August 2002. Authors' Addresses Larry Blunk Merit Network EMail: ljb(a)merit.edu Joao Damas Internet Software Consortium EMail: joao(a)psg.com Florent Parent Viagenie EMail: Florent.Parent(a)viagenie.qc.ca Andrei Robachevsky RIPE NCC EMail: andrei(a)ripe.net Blunk, et al. Expires May 20, 2004 [Page 20] Internet-Draft RPSLng November 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Blunk, et al. Expires May 20, 2004 [Page 21] Internet-Draft RPSLng November 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Blunk, et al. Expires May 20, 2004 [Page 22]

1 0

Last Call: 'RPSLng' to Proposed Standard
by The IESG 21 Nov '03

21 Nov '03

The IESG has received a request from an individual submitter to consider 'RPSLng' <draft-blunk-rpslng-01.txt> as a Proposed Standard. This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg(a)ietf.org or ietf(a)ietf.org mailing lists by 2003-09-23. File(s) can be obtained via http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt

6 40

Prototype release of RPSLng IRRToolSet
by Katie Petrusha 23 Oct '03

23 Oct '03

[ Apologies for multiple messages ] Dear Colleagues, The RIPE NCC is pleased to announce version 4.8.1 prototype release of IRRToolSet. RPSLng is an effort to extend RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used on the Internet. The prototype of IRRToolSet implements the Internet Draft Document draft-blunk-rpslng-01 (http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt) The prototype release contains peval, rpslcheck and RtConfig that already work with a new dictionary (you can also try the Web prototype for peval and RtConfig). Currently work is in progess to make other tools RPSLng compatible. More details can be found at: http://www.ripe.net/db/irrtoolset Please contact irrtoolset(a)ripe.net for any comments. -- Best regards, Katie Petrusha RIPE NCC

1 0

draft-blunk-rpslng-01.txt
by Randy Bush 18 Oct '03

18 Oct '03

There was considerable technical comment during the IETF last call. I have changed the status of this document to Publication-Requested / Revised I-D needed. randy

1 0