1. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 1 Extending RPSL: IPv6, multicast, … Presented by João Damas RIPE NCC

2. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 2 Outline Introduction Requirements First proposal Second proposal Questions

3. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 3 Introduction RPSL (RFC 2622). –Allows flexible specification of routing policies –Is defined only for IPv4 unicast routing –Allows limited future expandability More and more we hear requests to extend RPSL to be able to describe multicast and/or IPv6 routing policies.

4. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 4 Requirements Describe policy for multiple protocols –IPv6 –Multicast Minimise increase in complexity, especially for users Take into account compatibility with existing tools

5. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 5 First draft Described in draft-parent-multiprotocol-rpsl-00.txt (which supersedes draft-parent-ipv6-rpsl-00.txt) Presented at RIPE 41, January, Amsterdam Intention is to jumpstart the process of expanding RPSL.

6. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 6 draft-parent-multiprotocol-rpsl-00 (1) Introduces new address families [afi ] where: = enum[ipv4, ipv6, ipv4-multicast, ipv6-multicast] The afi syntax may be omitted under some circumstances, if appropriate defaults are defined.

7. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 7 draft-parent-multiprotocol-rpsl-00 (2) Route class route: 10.0.0.0/8 origin: AS1 route: afi ipv4 10.0.0.0/6 origin: AS1 route: afi ipv6 3ffe:ffff::/28 origin: AS1 Route-set class route-set: ipv6-martians members: afi ipv6 ff00::/8 members: afi ipv6 fe80::/10 …

8. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 8 draft-parent-multiprotocol-rpsl-00 (3) Peering-set class peering-set: AS1-v6 peering: AS1 afi ipv6 3ffe:ffff::1 at afi ipv6 3ffe:ffff::2 Autnum –Extend dictionary to define –afi (IPv4, IPv6)address family –safi (unicast, multicast)subsequent address family

9. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 9 draft-parent-multiprotocol-rpsl-00 (4) import: [protocol [afi(address-family) safi(subsequent-address-family)]] [into protocol ] from [action ] accept export: [protocol [afi(address-family)] safi(subsequent-address-family)]] [into protocol ] to [action ] announce Example: import: protocol BGP afi(ipv6), safi(unicast) from AS1 afi ipv6 3ffe:ffff::1 at afi ipv6 3ffe:ffff::2 accept AS1:RS-PROVIDER import: protocol BGP afi(ipv6), safi(unicast) from AS1-v6 accept AS1:RS-PROVIDER

10. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 10 Comments on the draft More consideration needs to be given to –currently available systems, both server and client side scripts will “choke” If they receive something like route: afi ipv4 10.0.0.0/6 origin: AS1 route: afi ipv6 3ffe:ffff::/28 origin: AS1 –clarity for the user who needs to write and read the new RPSL import: protocol BGP afi(ipv6), safi(unicast) from AS1 afi ipv6 3ffe:ffff::1 at afi ipv6 3ffe:ffff::2 accept AS1:RS-PROVIDER

11. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 11 Second proposal (1) Recognise three main items in RPSL –Objects where policy is described (autnum) May or may not be dependant on the address family. –Objects identifying prefixes and their relationship to ASNs (route) Fully dependant on the address family –shorthand notation objects (as-set,route-set,filter-set)

12. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 12 Second proposal (2) Create new route6 class route6: 3ffe:ffff::/28 origin: AS1 Clearly separates address family representation. Allows for query level selection of returned results and helps prevent current tools from facing unexpected input. It also reflects server side representation differences, since the prefix is a lookup key

13. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 13 Second proposal (3) autnum class –option would be to define import6 and export6 attributes inside the object. –Separates policy items for different address families –Is more clear for humans –existing tools are not faced with unexpected data Pitfall: –May require duplication of policy if it is your IPv4 and IPv6 policies are the same –Is less elegant from a pure language perspective Other classes –would follow the same pattern as for classes above

14. João Damas. APRICOT 2002, March 2002, Bangkok. http://www.ripe.net 14 Questions?