[6bone] 2001:478:: as /48

[Pim van Pelt]

Hoi,

The below prefix-list used to be used by me (and possibly others) only on
outgoing announcements. However, with all sorts of individuals
deliberately breaking the strict aggregation model by announcing and
transitting /48s, I sometimes saw traffic to one of my peers' customers
networks travel wicked paths, because they do send me aggregated routes
(thus filtering the /48) but their customers peer with other people as
well creating a more specific in my routing tables via operators who do
not use egress filtering.

This is why I have adapted the strict filtering in egress as well as
ingress these days. 

By the way, looking at the 'strict' prefix list below, I would like to
bring it to the general attention that '3ffe::/17' does no longer exist,
since we started to use the /32 prefixes in 3ffe:4000::/18, thus
chopping the lower half of the /16 in half. For 6bone, it is now:

3ffe::/18 ge 24 le 24
3ffe:4000::/18 ge 32 le 32
3ffe:8000::/17 ge 28 le 28

>From other places, I hear that having /48 or even /64 in the route table
could be 'acceptable'. One might argue that an operator with a large
router box with much memory can opt to have a 'full view' with all the
more specifics, and an operator with a smaller box can opt to have a
'strict full view' with only aggregated prefixes.

Nobody will lose connectivity in the latter case, if and only if we keep
on having at least a route to the more specific in the aggregating AS.
For me, I'll stick to BOFH mode (ie, strict filtering) until we have a
best common practice.

On Sun, Jul 21, 2002 at 11:35:47AM -0700, Michel Py wrote:
| Bill,
| 
| I don't see it as unaggregated and I believe I'm not the only one. I
| dropped my ipv6 prefix-lists and I have a BGP4+ feed from three
| different pTLAs.
| 
| Is there any document you can point us to that specifies that it should
| be unaggregated? It is possible that a very small portion of the 6bone
| will actually see a /48, as my understanding is a number of us do indeed
| use something more or less than:
| 
| ipv6 prefix-list strict seq 5 permit 3ffe::/17 ge 24 le 24
| ipv6 prefix-list strict seq 10 permit 3ffe:8000::/17 ge 28 le 28
| ipv6 prefix-list strict seq 15 permit 3ffe:4000::/18 ge 32 le 32
| ipv6 prefix-list strict seq 20 permit 2000::/3 ge 16 le 16
| ipv6 prefix-list strict seq 25 permit 2001::/16 ge 29 le 35
| ipv6 prefix-list strict seq 30 deny 2000::/3
| 
| [prefix-list stolen from Pim Van Pelt]
| 
| Michel.
| 
| 
| -----Original Message-----
| From: Bill Manning [mailto:bmanning@ISI.EDU] 
| Sent: Sunday, July 21, 2002 9:17 AM
| To: 6bone@ISI.EDU
| Cc: Bill Manning
| Subject: [6bone] 2001:478:: as /48
| 
| 
| 
| this prefix has/is being carved up into /48 and /64 subnets for
| use at exchange points and other infrastructure support services.
| 
| Do not expect to see it aggregated. 
| 
| -- bill manning
| _______________________________________________
| 6bone mailing list
| 6bone@mailman.isi.edu
| http://mailman.isi.edu/mailman/listinfo/6bone
| _______________________________________________
| 6bone mailing list
| 6bone@mailman.isi.edu
| http://mailman.isi.edu/mailman/listinfo/6bone

-- 
---------- - -    - - -+- - -    - - ----------
Pim van Pelt                 Email: pim@ipng.nl
http://www.ipng.nl/             IPv6 Deployment
-----------------------------------------------