[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt
On Tue, 20 Sep 2005, Marc Blanchet wrote:
You mean, after the routing table has already been irreversibly polluted
with junk, come back and review our past recommendations?
- no. you are missing the point.
- currently no recommendation. so /128 can fly.
- what is the number then, if not /48? I'm fine with better than /48, but I
thought that concensus will be difficult with a number less than /48.
- and if you read the text, /48 is the minimum.
- maybe you can provide some text?
No. If there is no appropriate IETF statement on this, the folks
probably think the IETF hasn't made a firm opinion on this, and seek
guidance from elsewhere. Many use strict filters, others relaxed,
some may not filter at all. That is, the lack of IETF guidance on
filtering doesn't mean the operators can't (and don't) filter --
operators seem to be capable of publishing some filtering suggestions
on their own (e.g., Gert's web page).
So, any guidance the IETF makes must be good, not simply "anything is
better than nothing".
Sorry, I don't see how that could fly. If we don't recommend (or at least
describe the tradeoffs of) filtering at the allocation boundaries, we'd
better not produce a document at all because the existance of such a
document would be interpreted as the IETF's go-ahead for putting the junk
in the routing tables.
so you are proposing /32? Can you provide text?
Ok, here's something to demonstrate a different starting point.
3.5. Global Unicast
The global unicast routes (2000::/3) [RFC3513] may be advertised in an
IGP or EGP.
3.5.1 Filtering on Allocation Boundaries
In IPv4 as of 2005, over 50% of routing table entries are used by
more-specific route advertisements [http://bgp.potaroo.net]. These are
a result of a number of sources such as misconfigurations, traffic
engineering, multihoming, switching providers without renumbering,
From the larger perspective, however, these are more or less
unnecessary "junk". In 6bone, prefix filters to weed out
more specifics were required [RFC2772] to weed out such routes.
This is also a valid practise for production networks as
it will help in keeping the routing table compact and clean;
the cleaner the global routing table is, the more difficult it
is for people to start polluting it.
Therefore, filtering based on the allocation boundaries is
recommended. For the sake of simplicity (as the allocation
boundaries have varied mainly between /19 and /32), the
policy could be to allow advertisements up to /32, and /35
for older allocations in 2001::/16, and the more specifics only
by exception. One particular exception to keep in mind in
particular is ARIN's critical internet infrastructure
micro-allocation block (2001:500::/32) where up to /48's
should be allowed.
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings