[ipv6-wg@ripe.net] RPSLng in the RIPE Whois Database
Dear Colleagues, Beginning Wednesday 29 December 2004, the RIPE Database will support RPSLng. RPSLng extends the Routing Policy Specification Language (RPSL) allowing description of IPv6 and multicast routing policies. It includes a new object type, ROUTE6, and new attributes, such as "mp-import:" and "mp-export:". RPSLng was submitted to the IETF to become an RFC. You can read the most recent draft at: http://www.radb.net/rpslng-08.html This change will not affect the current contents of the database. It is optional for any objects you maintain. The main differences for query users are as follows: - Currently a query for an IPv4 address or network may return INETNUM, ROUTE, and INET-RTR objects. A query for an IPv6 address or network can only return an INET6NUM object. After we put RPSLng into production, IPv6 queries will start to also return ROUTE6 and INET-RTR objects, if they are in the database. - Currently an inverse query (using the "-i" flag) for AUT-NUM objects may return ROUTE objects. After we put RPSLng into production, a query will return both ROUTE and ROUTE6 objects. If you want to limit your query, you can use the "-T" flag. For example, if you only want ROUTE objects returned to an inverse query, you can type: whois -h whois.ripe.net -T route -i origin AS3333 Please change your scripts if necessary. We will not move the contents of the RPSLng prototype Whois server to the RIPE Whois Database. You will have to create any objects that define your routing policy in the production RIPE Whois Database. You can update the RPSLng prototype Whois server until the start of January 2005. The query interface will be available until the end of January 2005. -- Shane Kerr Software Manager RIPE NCC
Hi,
Beginning Wednesday 29 December 2004, the RIPE Database will support RPSLng.
This is great, I really appreciate that. Now, any comments about registering route6-objects for 6to4 prefix (2002::/16)? I would suggest a solution like it is already done for the IPv4 part (192.88.99.0/24), perhaps even use the same maintainer. 2002::/16 isn't RFC3068 per se, but since 3068 and the appropriate parts in 3056 are strictly tied and 6to4 relays are mostly bidirectional (announcing IPv4 and IPv6 prefix) it wouldn't hurt to use RFC3068-MNT here, too. The initial object would need to be created by RIPE NCC though, due to missing mnt-routes in ::0/0. Bernhard
Hi Bernhard, On 2004-12-15 19:31:22 +0100, Bernhard Schmidt wrote:
Hi,
Beginning Wednesday 29 December 2004, the RIPE Database will support RPSLng.
This is great, I really appreciate that.
Now, any comments about registering route6-objects for 6to4 prefix (2002::/16)? I would suggest a solution like it is already done for the IPv4 part (192.88.99.0/24), perhaps even use the same maintainer. 2002::/16 isn't RFC3068 per se, but since 3068 and the appropriate parts in 3056 are strictly tied and 6to4 relays are mostly bidirectional (announcing IPv4 and IPv6 prefix) it wouldn't hurt to use RFC3068-MNT here, too.
The initial object would need to be created by RIPE NCC though, due to missing mnt-routes in ::0/0.
OK, we will add "mnt-routes: RIPE-NCC-RPSL-MNT" to the 0::/0 inet6num object during the transition. Regards,
Bernhard
-- Engin Gunduz RIPE NCC Software Engineering Department
participants (3)
-
Bernhard Schmidt
-
Engin Gunduz
-
Shane Kerr