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

[Michel Py]

> Pim van Pelt wrote:
> The below prefix-list used to be used by me (and possibly others)
> only on outgoing announcements.

This is consistent with me previously using it as ingress announcements,
as I am an end-site and you are a pTLA.

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

I agree.


> 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

Thanks for the precision.

> From other places, I hear that having /48 or even /64 in the
> route table could be 'acceptable'.

I still have to see any kind of document that makes it "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.

This has similarities with what ipv6mh is currently working on (for geo
prefixes); however, I can not see any reason to have PA specifics except
your own.



> 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.

Or a multihoming protocol.

Michel.