IPv6 routing policy by bestt571

VIEWS: 84 PAGES: 25

More Info
									IPv6 routing
policy

          APAN 30
           Hanoi
   11th   August, 2010
IPv6 is being deployed
• Many networks have deployed dual
  stack networks.

• The IPv6 routing table is growing

• More content is becoming available
  over IPv6. Google is now IPv6
  enabled to participating networks

• Does IPv6 routing happen by
  magic???
Routing policy
• IPv4 has been around a long time

• Tools have been developed for
  filtering routes and ensuring that
  traffic goes on optimal paths and
  implements policy for an organisation

• The IPv6 world has developed by the
  use of tunneling over an IPv4
  network leading to some interesting
  topologies.
Peering policy
• IPv6 has developed with different peering policies
  compared to IPv4

• Peering has been a lot more promiscuous than
  with IPv4 as organisations seek broader IPv6
  connectivity

• Peering has been built on tunnels in many cases.

• The distinction between peer and transit has been
  blurred.
IPv6 routes
• Strict
  – Based on the RIR allocations.


• Loose
  – To implement internal routing policy.


• Blackhole
  – If it happens in IPv4 land it will happen in IPv6


• Rich in policy
  – Using BGP community tags to express preference and control
    over paths
Policy generation within AARNet
• Use prefix filtering wherever possible

• Use BGP communities to
  restrict/advertise routes

• Try to keep advertisements as close to
  RIR resources as possible to externals.

• Prefixes are the real resource
–   AS Numbers are little more than tags
RPSL and IRRToolset
•   Use RPSL to define routing policy

•   Many routers to manage ~150

•   Use IRRToolset to implement defined policy on routers in
    a uniform way

•   Mileage varies as there is a lot of garbage in the IRRs

•   Generally successful, especially after the recent
    IRRToolset code cleanup

•   Works fine in the IPv4 world to develop rich policy
IPv6, RPSLng and IRRToolset
•   RPSLng provides multiprotocol extensions to RPSL

•   This covers unicast and multicast address families and
    IPv6

•   More complex

•   Instead of imports and exports you have mp-imports and
    mp-exports

•   More features and bugs than before!
The transition from RPSL to RPSLng
•   Certainly not clean

•   Confusion in code relating to each mp support

•   Requires more specific policy to handle dual environments

•   Could be classified as unworkable!

•   But there are glimmers of hope!
IPv4 Blackholing
• If you trust a prefix is received from a source
  then you can arrange to blackhole a subset of
  that prefix.

• Useful for diverting DOS traffic away from the
  network

• Can signal to upstreams to blackhole too

• The DOS traffic doesn’t even have to enter your
  network
   IPv4 Blackholing Policy
remarks:
remarks: IPv4 blackhole policy if community 7575:6 is received from a customer
remarks:
mp-import: afi ipv4.unicast {
            from AS-ANY action community = {7575:1000, 7575:6}; accept ANY;
       } refine {
            from AS-ANY action pref=50; next-hop=192.168.1.1; community = {7575:1};
            accept community.contains(7575:6);
       } refine {
            from AS64653 at 202.158.192.206 action community = {7575:2206, 7575:3003};
            accept AS7575:RS-AS64653^32 AND <^PeerAS+$>;
      }

  Accept /32 routes (ie host routes) from a trusted customer and send the packets
  to the null interface

  Put the route into iBGP and keep the 7575:6 tag so other routers in the domain
  blackhole

  At a transit router then send the route tagged no-export with the transit
  blackhole BGP community
   Lets choose an example
route-set: AS7575:RS-AS64653
members: 136.186.0.0/16
mp-members: 2001:388:6080::/48
descr:   swinburne
remarks: List of routes accepted from AS64653
mnt-by: MAINT-ASAARNET
changed: nobody@aarnet.edu.au 20100331
source: AARNET




  A route-set example showing both IPv4 and IPv6 members.

  The institution doesn’t have a public AS and is routed publicly under AS7575
    IPv6 Blackholing Policy
remarks:
remarks: IPv6 blackhole policy if community 7575:6 is received from a customer
remarks:
mp-import: afi ipv6.unicast {
            from AS-ANY action community = {7575:1000, 7575:6}; accept ANY;
       } refine {
            from AS-ANY action pref=50; next-hop=FFCC::1; community = {7575:1};
            accept community.contains(7575:6);
       } refine {
            from AS64653 at 2001:388:1::CE action community = {7575:2206, 7575:3003};
            accept AS7575:RS-AS64653^128 AND <^PeerAS+$>;
      }


   Accept /128 routes (ie host routes) from a trusted customer and send the
   packets to the null interface

   Put the route into BGP and keep the 7575:6 tag
   If you are a transit router then send the transit blackhole BGP community

   But it doesn’t work!
IPv6 Blackholing
• Certainly not clean
• Next-hop attribute seems not available for IPv6
  – a next-hop of 192.168.1.1 is not allowed
  – A next-hop of FC00::/64 is not accepted
  –   #ERROR: 517: mp-import: Malformed prefix
• Prefix filters for a network range are explicitly
  calculated
  –    2001:388:1::/48^128
      • Calculated as every single /128 prefix
      • Not as a range 2001:388:1::/48 ge 128 le 128


• Takes a long time to calculate!
      IPv6 Loose filters
remarks:
remarks: IPv6 policy on relaxed routes sent by a customer with community 7575:2 - no-export beyond AARNet
remarks: or 7575:5002 - no export to commodity
remarks:
mp-import: afi ipv6.unicast {
      from AS-ANY action community = {7575:1000}; accept ANY;
      } refine {
      from AS-ANY action community = {65535:65281}; accept community.contains(65535:65281);
      from AS-ANY action community = {65535:65282}; accept community.contains(65535:65282);
      from AS-ANY action community = {7575:2}; accept community.contains(7575:2);
      from AS-ANY action community = {7575:5002}; accept community.contains(7575:5002);
      } refine {
         from AS64653 at 2001:388:1::CE action community = {7575:2206, 7575:3003};
            accept AS7575:RS-AS64653^0-48 AND <^PeerAS+$>;
      }
IPv6 Loose filters


• Untidy implementation

• Prefix filters for a network range are explicitly
  calculated

• 2001:388::/32^0-48
  – Calculated as every single /48 prefix
  – Not as a range 2001:388:1::/32 le 48

• Could use smaller ranges but still untidy
IPv6 Strict filters
remarks:
remarks: strict IPv6 policy on routes sent by a customer
remarks: need to set 7575:2 on sub-allocations of our provider dependent allocation
remarks:
mp-import: afi ipv6.unicast {
     from AS-ANY action community = {7575:1000}; accept ANY;
     } refine {
     from AS-ANY action community = {7575:3}; accept community.contains(7575:3);
     from AS-ANY action community = {7575:4}; accept community.contains(7575:4);
     from AS-ANY action community = {7575:5}; accept community.contains(7575:5);
     from AS-ANY accept ANY;
     } refine
     from AS-ANY action pref=30; accept community.contains(7575:70);
     from AS-ANY action pref=20; accept community.contains(7575:80);
     from AS-ANY action pref=10; accept community.contains(7575:90);
     from AS-ANY accept ANY;
     } refine {
     from AS64653 at 2001:388:1::CE action community={7575:2206,7575:3003,7575:2};
         accept AS7575:RS-AS64653 AND <^PeerAS+$>;
     }


Fairly flexible policy for customer control
IPv6 Strict filters


• These work! 1 out of 3 ain’t bad!

• Could be a basis for generating flexible policy on
  all IPv6 prefixes?

• Each stanza of our autnum object creates a
  specific set of prefixes

• Why not use this to generate IPv6 policy which
  is close to IPv4 policy? Certainly a kludge …
Options

1. Rewrite IRRToolset?
2. Do a perl script kludge?

Option 2 is easier …
Create a router template

Easy to create a template
 covering both IPv4 and IPv6
IPv4 segment of template
router bgp 7575
!
 neighbor 202.158.200.142 remote-as 64653
 neighbor 202.158.200.142 send-community
 neighbor 202.158.200.142 soft-reconfiguration inbound
 neighbor 202.158.200.142 default-originate route-map DEFAULT-ORIGINATE-IPv4
 neighbor 202.158.200.142 ebgp-multihop 2
!
 address-family ipv4 multicast
 neighbor 202.158.200.142 send-community
 neighbor 202.158.200.142 soft-reconfiguration inbound
 neighbor 202.158.200.142 default-originate route-map DEFAULT-ORIGINATE-IPv4
 neighbor 202.158.200.142 route-map AS64653-IPv4-1-IMPORT in
 neighbor 202.158.200.142 route-map AS64653-IPv4-1-EXPORT out
 exit-address-family
!
@RtConfig set cisco_map_name = "AS%d-IPv4-1-IMPORT"
@RtConfig import AS7575 202.158.192.206 AS64653 202.158.200.142
@RtConfig set cisco_map_name = "AS%d-IPv4-1-EXPORT"
@RtConfig export AS7575 202.158.192.206 AS64653 202.158.200.142
!
IPv6 segment of template
router bgp 7575
!
 neighbor 2001:388:1:301C::2 remote-as 64653
!
 address-family ipv6
 neighbor 2001:388:1:301C::2 send-community
 neighbor 2001:388:1:301C::2 soft-reconfiguration inbound
 neighbor 2001:388:1:301C::2 default-originate route-map DEFAULT-ORIGINATE-IPv6
 exit-address-family
!
 address-family ipv6 multicast
 neighbor 2001:388:1:301C::2 send-community
 neighbor 2001:388:1:301C::2 soft-reconfiguration inbound
 neighbor 2001:388:1:301C::2 default-originate route-map DEFAULT-ORIGINATE-IPv6
 neighbor 2001:388:1:301C::2 route-map AS64653-IPv6-1-IMPORT in
 neighbor 2001:388:1:301C::2 route-map AS64653-IPv6-1-EXPORT out
 exit-address-family
!
@RtConfig set cisco_map_name = "AS%d-IPv6-1-IMPORT"
@RtConfig import AS7575 2001:388:1::CE AS64653 2001:388:1:301C::2
@RtConfig set cisco_map_name = "AS%d-IPv6-1-EXPORT"
@RtConfig export AS7575 2001:388:1::CE AS64653 2001:388:1:301C::2
!
end
The process


• Edit the autnum object

• Put it in your favourite IRR
  –   We run our own irrd as we have lots of private objects



• Create/Edit a template file for the router

• Use a perl script to generate a working BGP
  config covering both IPv4, IPv6, unicast and
  multicast
The results


• A flexible configuration, uniformly applied,
  giving institutions and customers the ability to
  control their routing

• A large and complex set of route-maps that if
  done manually would lend itself to typos and
  misconfiguration
Thank You

								
To top