RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?

[Chris Welti]

Dear IPv6 (and IPv4) network operators

RIPE has recently published RIPE-555 (Address space managed by the RIPE NCC), which
replaces RIPE-510.

With RIPE-510 (http://www.ripe.net/ripe/docs/ripe-510), it was quite clear that
all IPv6 address allocations smaller than a /32 (longer prefixes) were coming out of
just a few special ranges:
a) Internet Exchange Points: up to /64 out of 2001:7f8::/32
b) Root Name Servers: up to /64 out of 2001:7f8::/29
c) Anycasting TLD nameservers: /48 out of 2001:678::/29
d) IPv6 PI address space: up to /64 out of 2001:678::/29

Now, the new document RIPE-555 (http://www.ripe.net/ripe/docs/ripe-555), drops all
these special ranges except for IPv6 PI space.

The section Longest Prefix Tables, which always included a list of IPv4 & IPv6 prefix
ranges and their longest allocated or assigned prefix in that range has been
drastically reduced to just read as follows:

"The smallest prefix assigned by the RIPE NCC from any IPv4 range is a /29.
The smallest prefix assigned by the RIPE NCC from any IPv6 range is a /48."

Additionally the section "Routing decisions" has been adjusted to just say:
"Routing decisions are the responsibility of network operators".
The sentence "Network operators taking routing decisions based on prefix length
are requested and encouraged to route at least blocks of sizes corresponding to
the longest prefix and larger"

In the past we have used RIPE-510 and its predecessors as a basis for our martian
filters, where we deny prefixes that are longer than the minimum allocation sizes
for a particular address range allocated/assigned by RIPE.

To me as an operator this raises the question on how I should now filter martians for
the RIPE region?
Since I can not rely on the fact that longer prefix lengths just happen in
certain well defined ranges (minimum allocation per address range) anymore,
I see only three possibilites:

1) Generate a prefix-list out of
ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest
which includes all valid allocated/assigned IPv4 and IPv6 prefixes. Then only accept
those prefixes. That list would contain hundreds of thousands of entries and would have
to be built at least daily, so newly allocated prefixes can be properly accepted.

2) Just filter out prefixes that are longer than /48 for v6 and longer than /29
for v4 and keep all the rest.

3) Still filter the way we did before and risk that new "valid" longer prefix allocations
are not accepted.

Option 1 is not really feasible due to the huge size of the prefix-list

Option 2 means that basically I'm opening up the possibility for accidential (leaks)
or purposeful (traffic engineering) leaks of potentially 65535 /48 v6 prefixes per /32,
and there are a lot of possible /32s :)
Even though it's less for v4 it's still a couple of millions of /29 v4 prefixes
That could result in a lot of addresses in the routing table!

Option 3 also does not sound like a good idea, as that would lead to holes in the routing
table.

Similar concerns have also been raised by my colleague Alex on the [ncc-services-wg] list
but so far nobody else has chimed in.

So how and on what basis do you create your martian filters?
Or is this a non-issue for you?

Best regards,
Chris / AS559

SWITCH
Serving Swiss Universities
--------------------------
Chris Welti, Network Engineer
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 30, fax +41 44 268 15 68
chris.welti at switch.ch
http://www.switch.ch