[6bone] Summer cleanup time for IPv6 aggregation!

[John Fraizer]

On Fri, 26 Jul 2002, Roger Jorgensen wrote:
> 
> What's wrong with letting through 3ffe::/16 le /32 ? (know it break the current
> RFC), but wouldn't it be an idea to let both 2001 and 3ffe space be aggregated
> upto /32 ? (2001 are, but 3ffe aren't)

It's all about aggregation.  Since not all of 3ffe://16 is allocated as
/32's, not all of it should be accepted as /32's.  We should only accept
this address space up to the bit boundry that is allocated.

Beyond that, when you requested your pTLA, you should recall this part of
the application:

      "The pTLA Applicant MUST commit to abide by the current 6Bone
      operational rules and policies as they exist at time of its
      application, and agree to abide by future 6Bone backbone
      operational rules and policies as they evolve by consensus of the
      6Bone backbone and user community."


Note this portion of RFC2772:


   "All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA
   delegation (currently /24 or /28) to other 6bone pTLAs unless special
   peering arrangements are implemented. When such special peering
   aggreements are in place between any two or more 6bone pTLAs, care
   MUST be taken not to leak the more specifics to other 6bone pTLAs not
   participating in the peering aggreement. 6bone pTLAs which have such
   agreements in place MUST NOT  advertise other 6bone pTLA more
   specifics to downstream 6bone pNLAs or leaf sites, as this will break
   the best-path routing decision."


Somehow, I don't remember entering into a peering agreement that included
the following:

2001:6c0:1fff:ffd0::/60
2001:7f8:1::/64
3ffe:1200:3028:88a0::/64
3ffe:8090:4800:4e20::/64
3ffe:8090:4800:c000::/64


> And on a later stage, maybe we should change the RFC and allow even something
> bigger than /32 be let through, /40 ? (/48's are too big to be let through 
> on a RFC base)

Why?  There is no reason to do this.  Let the /35, /32, /28, /24 (whatever
the RIR or 6bone allocation is) through the filters.  Anything more
specific is reachable by the aggregate and we don't end up with a v6
global routing table that is messed up like the current v4 table.

Folks, the "redistribute connected" is *NOT* your friend here.  There is
no reason for a /64 or /128 to be in the routing table.  That is what your
IGP is for.


There are so many EASY ways to keep the global table clean.

(1) aggregate-address X:X::X:X/M summary-only   It's simple, it's elegant,
it works.

(2) prefix-list filter your peers.  If you're not already doing this, you
should be!   If you have a downstream BGP peer who is going to be sending
you a /40 or /48 announcement, set up a route-map for this peer like so:



ipv6 prefix-list DOWNSTREAM permit XX::XX/48
ipv6 prefix-list subTLA-only seq 5 deny 2001::/16 ge 36
ipv6 prefix-list subTLA-only seq 10 deny 3ffe::/18 ge 25
ipv6 prefix-list subTLA-only seq 15 deny 3ffe:4000::/18 ge 33
ipv6 prefix-list subTLA-only seq 20 deny 3ffe:8000::/22 ge 29
ipv6 prefix-list subTLA-only seq 25 permit ::/0 ge 1
!
route-map DOWNSTREAM permit 10
 match ipv6 address prefix-list DOWNSTREAM
 set community no-export additive
!
route-map DOWNSTREAM permit 20
 match ipv6 address prefix-list subTLA-only
!

You will see the /48 (or whatever it is) in YOUR routing table but, you
are doing the responsible thing and marking it as no-export and not
polluting the GLOBAL table with that garbage.


(3) Apply a prefix list, like the above subTLA-only both inbound and
outbound to your transit peer connections.

This truely is not that difficult.  I don't understand the overwhelming
resistance to doing things right.



---
John Fraizer              | High-Security Datacenter Services |
EnterZone, Inc            | Dedicated circuits 64k - 155M OC3 |
http://www.enterzone.net/ | Virtual, Dedicated, Colocation    |