IPv6 routing policy

Document Sample
IPv6 routing policy Powered By Docstoc
					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

				
DOCUMENT INFO
Shared By:
Tags: ipv6, routing
Stats:
views:84
posted:3/13/2011
language:English
pages:25
Description: One advantage of IPv6 is to provide flexible routing mechanism. Allocation of IPv4 network ID as the means used to require in the Internet backbone routers on the maintenance of large routing table. These routers need to know all the routes for transmission may be directed to any node on the Internet data packets. Through its ability to aggregate address, IPv6 supports flexible addressing modes, greatly reduces the size of the routing table. In addressing this new structure, the intermediate routers must only follow the local part of its network in order to properly forward the message.