1 / 14

Extending RPSL: IPv6, multicast, …

Extending RPSL: IPv6, multicast, …. Presented by João Damas RIPE NCC. Outline. Introduction Requirements First proposal Second proposal Questions. Introduction. RPSL (RFC 2622). Allows flexible specification of routing policies Is defined only for IPv4 unicast routing

waseem
Download Presentation

Extending RPSL: IPv6, multicast, …

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Extending RPSL:IPv6, multicast, … Presented by João Damas RIPE NCC

  2. Outline • Introduction • Requirements • First proposal • Second proposal • Questions

  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. Requirements • Describe policy for multiple protocols • IPv6 • Multicast • Minimise increase in complexity, especially for users • Take into account compatibility with existing tools

  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. draft-parent-multiprotocol-rpsl-00(1) • Introduces new address families [afi <address-family>] <address-prefix> where: <address-family> = enum[ipv4, ipv6, ipv4-multicast, ipv6-multicast] The afi <address-family> syntax may be omitted under some circumstances, if appropriate defaults are defined.

  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. 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. draft-parent-multiprotocol-rpsl-00(4) import: [protocol <protocol> [afi(address-family) safi(subsequent-address-family)]] [into protocol <protocol>] from <peering> [action <action>] accept <filter> export: [protocol <protocol> [afi(address-family)] safi(subsequent-address-family)]] [into protocol <protocol>] to <peering> [action <action>] announce <filter> 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. 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. 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. 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. 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. Questions?

More Related